Visualizzazione dei risultati da 1 a 8 su 8
  1. #1

    Bloccare un record se "aperto" (Transazioni, InnoDb)

    Salve,
    come da titolo ho bisogno di evitare che se l'utente A ha aperto un record per Modificarlo/Cancellarlo, l'utente B possa eseguire operazioni su quel record.
    Premetto che le tabelle che utilizzo sono di tipo InnoDB e che utilizzo la versione 5.0.19 del MySql.

    Ho provato a fare la query in questo modo:

    SELECT * FROM fornitori LEFT OUTER JOIN tabprovincie ON fornitori.CodProvincia = tabprovincie.CodProvincia WHERE CodFornitori = '$CodicePassato' FOR UPDATE

    Ho letto che "FOR UPDATE" metteva la "righa" in stato di "Lock"... ma facendo delle prove non sembra essere così...

    Aggiungo che io in una pagina eseguo quella query, e in un'altra pagina l'UPDATE o il DELETE a seconda di quello che viene selezionato.

    Ho letto e cercato molto, ma non riesco ad uscirne fuori.

    Sapete aiutarmi?

    Grazie!

  2. #2

  3. #3
    Utente di HTML.it L'avatar di mark2x
    Registrato dal
    Nov 2005
    Messaggi
    1,940
    Semplicemente: l'utente B deve aspettare prima di eseguire tale operazione o gli dev'esser negata punto e basta?

    Se vale la seconda ipotesi, puoi includere un flag nella tua tabella. Quando si inizia la transazione lo setti ad 1, quando finisce a zero.
    L'utente B può operare sse il flag è a 0 - o dopo un timeout.

    Basta o proprio vuoi modificare la concorrenza a livello db?

    [.:: JaguarXF ::.]
    __________________

  4. #4
    Quello che vorrei fare, trattandosi di un'applicativo gestionale, è fare in modo che due o più persone non possono lavorare sullo stesso record.

    Cosa intendi per "modificare la concorrenza a livello db"?

    Grazie!

  5. #5
    Utente di HTML.it L'avatar di mark2x
    Registrato dal
    Nov 2005
    Messaggi
    1,940
    Intendevo usare le transazioni vere e proprie.

    Cmq, io non so esattamente ciò che intendi, ma è ovvio che tutti i db gestiscono le richieste in concorrenza: se un utente invia una query di aggiornamento su un'entry, ovvio è che il server db non permette ad altri di leggerla nè tantomeno di modificarla fintantoche il primo utente non ha finito...

    Non so se chiedevi questo o volevi spingerti più in la.
    Più in là vuol dire che un insieme di query devono essere considerate come una sola. In qs caso si parla di transazioni (su InnoDB puoi).

    [.:: JaguarXF ::.]
    __________________

  6. #6
    Il problema è che dai test che ho fatto MySql non gestisce l'accesso ai record in modo automatico.
    Ovvero:
    Ipotiziamo che l'utente A accede alla riga 2 della tabella Prova.
    Teoricamente all'utente B deve essere vietato di accedere alla riga 2 della tabella Prova e di effettuare su essa operazioni di Update e Delete.

    Purtroppo questo succede ed è per questo che devo gestire il tutto con le transazioni.

    Il problema è che ho provato in vari modi ma non ci sono riuscito.
    A questo punto mi servirebbe un'esempio funzionante in modo da poterlo studiare e in caso adattare alle mie esigenze.

    Grazie!

  7. #7
    Utente di HTML.it L'avatar di mark2x
    Registrato dal
    Nov 2005
    Messaggi
    1,940
    Originariamente inviato da Web01
    Ipotiziamo che l'utente A accede alla riga 2 della tabella Prova.
    Accede vuol dire legge o scrive?

    Ponendo che legga e non abbia finito di farlo, o che scriva:

    Teoricamente all'utente B deve essere vietato di accedere alla riga 2 della tabella Prova e di effettuare su essa operazioni di Update e Delete.
    Certo.

    Purtroppo questo succede
    Maffigurati!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!

    [.:: JaguarXF ::.]
    __________________

  8. #8
    FOR UPDATE nega la scrittura simultanea se non erro ma non la lettura, ergo entrambi possono leggere quella tabella ma solo il rpimo potrà verificarla, cmq è un'operazione che va fatta sulla stessa pagina, se fai una query FOR UPDATE e poi chiudi la connessione a mysql, o counque la pagina finisce di essere elaborata, questa mi sa che viene rilasciata in automatico ergo il FOR UPDATE in pagina A non ti serve a niente mentre in pagina B, dopo la scelta, la query dovrà sfruttare il lock in fase di update, per l'appunto.

    dico male ? ... soluzione, unaflag se la tabela è impegnata temporaneamente, cancellata se l'utente sceglie altro o esce
    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.