Allora: GET_LOCK(<lock_name>, <timeout>) controlla se <lock_name> è già preso; se è già preso, aspetta timeout secondi, che si liberi. Se non si libera, dopo che il timeout è scaduto restituisce 0. Se si libera, o se non era preso, restituisce 1 e l'esecuzione del programma può continuare. Come vedi fa tutto da solo, senza bisogno di IS_FREE_LOCK().Originariamente inviata da brancomat
Non sono molto esperto, ma non vedo dove sia la contraddizione.
IS_FREE_LOCK torna subito un risultato, sia che il lock ci sia, sia no.
Non serve un timeout. Se so già che il LOCK esiste, allora è inutile cercare di fare un GET_LOCK per attendere che il timeout scada, e viceversa.
Come detto potrebbe esistere il caso in cui ci sia un GET/FREE lock, da parte di qualcun altro, mentre viene eseguito il codice tra IS_FREE e GET_LOCK. In questo caso l' "ottimizzazione" non serve a nulla, ma alla fine mi sembra una scelta comunque logica.
O no? ()
Se poi uno non vuole un timeout (ma perché?) basta passargli 0.
Sì.. se per esempio inserisci 3 righe la sintassi SQL è:Francamente non so come fare, ma penso comunque di riuscirci, accodando le varie INSERT in una stringona PHP intervallate con ;.
Proverò
INSERT nome_tab (a, b) VALUES
(1, 2), (3, 4), (5, 6).
Rispondi quotando