Mysql, PHP, contatori, lock table & locks in generale

[brancomat]

Se il LOCK è preso è giusto tornare subito con un messaggio d'errore, senza aspettare il timeout.

lock_wait... ecco finalmente qualcosa che inizia ad assomigliare alla soluzione!!! grazieee!!!!

I contatori riguardano la creazione di pratiche da parte di un consorzio che poi vengono date ai vari consorziati, i quali a loro volta li subappaltano a collaboratori esterni.
Per individuare chi abbia in carico la pratica si usano serie diverse tipo 1xxxxx sono le pratiche di tizio, 2xxxxx sono le pratiche di caio e così via. Tizio, Caio e gli altri possono anche prenotare le pratiche, ovvero prendersi un certo stock, che poi verranno compilate in seguito.

In pratica Tizio può riservarsi le pratiche 100010-100020 (ecco l'avanzamento del contatore che non è "+1" sempre), così quando Caio andrà a predisporre le pratiche sempre di tizio registrerà la 100021.

Spero grosso modo si capisca

[in the web]

Se il LOCK è preso è giusto tornare subito con un messaggio d'errore, senza aspettare il timeout.

Se fai GET_LOCK(xxx, 5), hai messo un timeout di 5 secondi. Con IS_FREE_LOCK il timeout non c'è. E' un po' contraddittorio

lock_wait... ecco finalmente qualcosa che inizia ad assomigliare alla soluzione!!! grazieee!!!!

Spero proprio che lo sia, oltre ad assomigliare! Se dovessi avere ancora problemi non cambiare tutto il codice, vediamo di capire dov'è il problema.

I contatori riguardano la creazione di pratiche da parte di un consorzio che poi vengono date ai vari consorziati, i quali a loro volta li subappaltano a collaboratori esterni.
Per individuare chi abbia in carico la pratica si usano serie diverse tipo 1xxxxx sono le pratiche di tizio, 2xxxxx sono le pratiche di caio e così via. Tizio, Caio e gli altri possono anche prenotare le pratiche, ovvero prendersi un certo stock, che poi verranno compilate in seguito.

In pratica Tizio può riservarsi le pratiche 100010-100020 (ecco l'avanzamento del contatore che non è "+1" sempre), così quando Caio andrà a predisporre le pratiche sempre di tizio registrerà la 100021.

Spero grosso modo si capisca

Grazie, mi hai tolto la curiosità

Consiglio: potresti inserire N righe con un'unica INSERT. E' un po' più efficiente perché, anche se devi inserire 50 record, PHP e MySQL si parlano una volta sola.

[brancomat]

Se fai GET_LOCK(xxx, 5), hai messo un timeout di 5 secondi. Con IS_FREE_LOCK il timeout non c'è. E' un po' contraddittorio

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? ()

Consiglio: potresti inserire N righe con un'unica INSERT. E' un po' più efficiente perché, anche se devi inserire 50 record, PHP e MySQL si parlano una volta sola.

Francamente non so come fare, ma penso comunque di riuscirci, accodando le varie INSERT in una stringona PHP intervallate con ;.
Proverò

[in the web]

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? ()

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().

Se poi uno non vuole un timeout (ma perché?) basta passargli 0.

Francamente non so come fare, ma penso comunque di riuscirci, accodando le varie INSERT in una stringona PHP intervallate con ;.
Proverò

Sì.. se per esempio inserisci 3 righe la sintassi SQL è:
INSERT nome_tab (a, b) VALUES
(1, 2), (3, 4), (5, 6).

[brancomat]

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().

Non è una necessità, è una ottimizzazione, o almeno così lo vedo io.
Supponiamo che IS_FREE_LOCK impieghi 0,1 secondi, GET_LOCK 0,2 secondi e il timeout sia 5 secondi.

Ricapitolo: ci sono 3 casi.
1. Il lock esiste
2. Il lock non esiste
3. Il lock viene preso da qualcuno durante l'esecuzione del mio script, esattamente tra il pezzo con IS_FREE e GET_LOCK

Nel caso 1. usando IS_FREE+GET_LOCK la durata è 0,1 secondi invece di 5,2. Quindi ci guadagno, e tanto.

Nel caso 2. con IS_FREE+GET_LOCK la durata è 0,3 secondi invece di 0,2 = 0,1 secondi in più. Quindi non ci perdo in sostanza nulla.

Nel caso 3. Se viene preso un LOCK (da qualcuno di diverso) tra IS_FREE e GET_LOCK allora il tempo è 5,3 secondi, invece di 5,2. Ci perdo un pochino, ma proprio poco, e devo essere davvero sfigato per il caso 3.

In pratica poca spesa... tanta resa...

[in the web]

Ciao,

Mi hai incuriosito.

Puoi spiegarmi cosa succede?

Non ne ho idea, non sono una di quelle 100 persone in tutto il mondo
Se cerchi nella documentazione c'è una sintassi precisa da rispettare se vuoi usare LOCK TABLES con InnoDB, dovresti farlo con una console, mentre con un'altra console guardi nel performance_schema quali lock vengono presi, e magari tra un'istruzione e l'altra provi a fare qualcosa con una terza console, per vedere come si comporta.
Ma è più semplice non usarlo!

Nel caso 1. usando IS_FREE+GET_LOCK la durata è 0,1 secondi invece di 5,2. Quindi ci guadagno, e tanto.

E allora perché usi 5? Usa 0

[in the web]

Comunque nel caso che dici tu non aspetteresti mai 5 secondi: se la transazione dura 0.2 secondi, aspetti 0.2 secondi. 5 è il massimo. Io metterei 2, se metti 0 GET_LOCK non aspetta nulla e restituisce subito 0. In qualsiasi caso, is_free_lock non ti aiuta