Visualizzazione dei risultati da 1 a 10 su 14

Hybrid View

  1. #1
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da in the web Visualizza il messaggio
    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ò

  2. #2
    Quote Originariamente inviata da brancomat Visualizza il messaggio
    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.


    Quote Originariamente inviata da brancomat Visualizza il messaggio
    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).
    STK/Unit: Unit Test framework per MariaDB
    http://stk.wikidot.com/stk-unit

  3. #3
    Utente bannato
    Registrato dal
    Jul 2013
    Messaggi
    290
    Quote Originariamente inviata da in the web Visualizza il messaggio
    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...

  4. #4
    Quote Originariamente inviata da mydb Visualizza il messaggio
    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!


    Quote Originariamente inviata da brancomat Visualizza il messaggio
    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
    STK/Unit: Unit Test framework per MariaDB
    http://stk.wikidot.com/stk-unit

  5. #5
    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
    STK/Unit: Unit Test framework per MariaDB
    http://stk.wikidot.com/stk-unit

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.