Visualizzazione dei risultati da 1 a 10 su 10
  1. #1
    Utente di HTML.it
    Registrato dal
    Apr 2005
    Messaggi
    66

    flusso per lock tabelle mysql

    Ho letto varia documentazione sull'argomento nonché vari messaggi in questo forum, ma non sono riuscito a capire un aspetto del lock delle tabelle mysql tramite php, che è il seguente:
    - se la mia applicazione web (es. sistema di prenotazioni) è costituita da più pagine/script php ognuna delle quali rappresenta uno step dell'applicazione,
    - dal momento che in ogni pagina la connessione al db myqsl viene aperta all'inizio (mysql_connect) e chiusa alla fine (mysql_close),
    - se in una pagina intermedia faccio il LOCK di alcune tabelle e ho bisogno che questo duri fino all'ultima pagina (ovvero fino all'ultimo step, dove faccio l'unlock), il lock mi dura effettivamente fino a quest'ultimo script? o la chiusura della connessione al db tramite mysql_close nello stesso script in cui faccio il lock causa il rilascio delle tabelle?

  2. #2
    Utente di HTML.it
    Registrato dal
    Apr 2005
    Messaggi
    66
    Nessuno mi sa aiutare? Sarà perché ci sono tante richieste al forum?

  3. #3
    Utente di HTML.it
    Registrato dal
    Apr 2005
    Messaggi
    66

    Re: flusso per lock tabelle mysql

    Siccome potrebbe essere utile ad altri, mi rispondo da solo in seguito ad una lettura dell'apposito capitolo dell'ottimo libro "Applicazioni web database con PHP e MySQL" di Hugh E. William & David Lane, anno 2005, editore Hops Tecniche nuove.

    Originariamente inviato da Andreau
    Ho letto varia documentazione sull'argomento nonché vari messaggi in questo forum, ma non sono riuscito a capire un aspetto del lock delle tabelle mysql tramite php, che è il seguente:
    - se la mia applicazione web (es. sistema di prenotazioni) è costituita da più pagine/script php ognuna delle quali rappresenta uno step dell'applicazione,
    - dal momento che in ogni pagina la connessione al db myqsl viene aperta all'inizio (mysql_connect) e chiusa alla fine (mysql_close),
    - se in una pagina intermedia faccio il LOCK di alcune tabelle e ho bisogno che questo duri fino all'ultima pagina (ovvero fino all'ultimo step, dove faccio l'unlock), il lock mi dura effettivamente fino a quest'ultimo script? o la chiusura della connessione al db tramite mysql_close nello stesso script in cui faccio il lock causa il rilascio delle tabelle?
    La seconda che avevo detto, ovvero: la chiusura della connessione con mysql_close determina il rilascio delle tabelle come con unlock, tuttavia è buona norma fare l'unlock prima della sconnessione .
    Tutte le operazioni di insert a rischio di concorrenzialità devono quindi preferibilmente avvenire tramite un solo script php, a meno che non si effettui una sistema per verificare, ad ogni passaggio, che non siano state fatte nel frattempo modifiche da altri utenti (ed io in effetti ho fatto così: il primo script determina la disponibilità di camere, il secondo inserisce la prenotazione previa verifica che ci sia ancora disponibilità tramite analoga query del primo). Un altro modo consiste nell'utilizzare una o più "tabelle di appoggio" che servono ad inserire temporaneamente i nuovi record che vengono in un secondo tempo copiati nella tabella in cui devono stare (è un po' complicato da spiegare in due parole, ma se a qualcuno interessa lo posso riportare in modo più approfondito).
    Ciao

  4. #4
    lock in read/write per una o più operazioni di insert, update, o delete ed in una sola pagina, il resto serve a poco (inteso come lock su tutto a prescindere).

    Di solito, le operazioni in scrittura sono le prime della lista, quindi lock ed unlock esplicito sul primo file che si occupa di aggiornare, inserire, o eliminare i dati, al fine di presentare la pagina già aggiornata qualora ci siano poi operazioni in lettura.

    In soldoni, per dare una risposta aggiornata l'ordine è scrivi ed in caso leggi, poichè se hai un sistema leggi, poi scrivi, poi leggi, c'è qualcosa di sbagliato nella logica dell'applicazione.

    Se invece non ti servono dati aggiornati, usi il delay sulle query, select a parte e dove non ti serve sapere il numero di linee affette, ad esempio, e vai tranquillo.

    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  5. #5
    il tuo sistemino puoi farlo facile facile usando lo strumento apposito, e cioè le transazioni (con tabelle InnoDB, non MyIsam). Con il lock di intere tabelle, oltre ad avere prestazioni peggiori, ottieni giusto un paliativo.

  6. #6
    Originariamente inviato da skidx
    il tuo sistemino puoi farlo facile facile usando lo strumento apposito, e cioè le transazioni (con tabelle InnoDB, non MyIsam). Con il lock di intere tabelle, oltre ad avere prestazioni peggiori, ottieni giusto un paliativo.
    oltre il fatto che in write le select dovranno aspettare comunque il release della tabella ... si, in effetti transazioni e pace
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  7. #7
    Originariamente inviato da andr3a
    oltre il fatto che in write le select dovranno aspettare comunque il release della tabella ... si, in effetti transazioni e pace
    no, su innodb il lock necessario alle transazioni è a livello di riga, non di tabella.

    Significa che se lui per la sua prenotazione fa una SELECT ... FOR UPDATE di un particolare record, sul resto della tabella le altre transazioni scrivono e leggono in simultanea senza dover aspettare niente.

  8. #8
    Originariamente inviato da skidx
    no, su innodb il lock necessario alle transazioni è a livello di riga, non di tabella.
    parlavo di MyISAM, spesso scelte per altri motivi (copy e incolli i files o sincronizzi via rsync se non vuoi replication oppure tabelle statiche che volano per velocità di lettura)
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

  9. #9
    Originariamente inviato da andr3a
    parlavo di MyISAM, spesso scelte per altri motivi (copy e incolli i files o sincronizzi via rsync oppure tabelle statiche che volano per velocità di lettura)
    ma con myisam non hai le transazioni, l'ho scritto nel primo post, quindi son due discorsi mutuamente esclusivi.
    O usi le transazioni (quindi niente myisam per quei particolari dati) oppure non le usi, e allora hai tutte le problematiche connesse al lock a livello di tabella che tu dicevi.

  10. #10
    Originariamente inviato da skidx
    ma con myisam non hai le transazioni, l'ho scritto nel primo post, quindi son due discorsi mutuamente esclusivi.
    O usi le transazioni (quindi niente myisam per quei particolari dati) oppure non le usi, e allora hai tutte le problematiche connesse al lock a livello di tabella che tu dicevi.
    io dicevo, transazioni se possibili (ergo no MyISAM), quanto ho già scritto se l'engine è MyISAM.
    Formaldehyde a new Ajax PHP Zero Config Error Debugger

    WebReflection @WebReflection

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.