MySQL: transazioni vs tabelle di blocco

Sono un po 'confuso con le transazioni rispetto al blocco delle tabelle per garantire l'integrità del database e assicurarmi che SELECT e UPDATE rimangano sincronizzati e nessun'altra connessione interferisca con esso. Ho bisogno di:

SELECT * FROM table WHERE (...) LIMIT 1

if (condition passes) {
   // Update row I got from the select 
   UPDATE table SET column = "value" WHERE (...)

   ... other logic (including INSERT some data) ...
}

Devo assicurarmi che nessun'altra query interferisca e funzioni allo stesso modo SELECT (leggendo il "vecchio valore" prima che la connessione termini l'aggiornamento della riga.

So di poter impostare per impostazione predefinita LOCK TABLES tablesolo per assicurarmi che solo 1 connessione lo stia facendo e sbloccarlo quando ho finito, ma sembra eccessivo. Il wrapping di questo in una transazione farebbe la stessa cosa (assicurandosi che nessun'altra connessione tenti lo stesso processo mentre un'altra è ancora in fase di elaborazione)? O sarebbe SELECT ... FOR UPDATEo SELECT ... LOCK IN SHARE MODEsarebbe meglio?

Il blocco delle tabelle impedisce ad altri utenti di DB di influenzare le righe / tabelle che hai bloccato. Ma i blocchi, di per sé, NON assicureranno che la tua logica esca in uno stato coerente.

Pensa a un sistema bancario. Quando paghi una fattura online, ci sono almeno due account interessati dalla transazione: il tuo account, da cui viene prelevato il denaro. E il conto del destinatario, in cui viene trasferito il denaro. E il conto della banca, sul quale depositeranno felicemente tutte le commissioni di servizio addebitate sulla transazione. Dato (come tutti sanno oggigiorno) che le banche sono straordinariamente stupide, diciamo che il loro sistema funziona in questo modo:

$balance = "GET BALANCE FROM your ACCOUNT";
if ($balance < $amount_being_paid) {
    charge_huge_overdraft_fees();
}
$balance = $balance - $amount_being paid;
UPDATE your ACCOUNT SET BALANCE = $balance;

$balance = "GET BALANCE FROM receiver ACCOUNT"
charge_insane_transaction_fee();
$balance = $balance + $amount_being_paid
UPDATE receiver ACCOUNT SET BALANCE = $balance

Ora, senza blocchi e transazioni, questo sistema è vulnerabile a varie condizioni di gara, la più grande delle quali è l'esecuzione di più pagamenti sul tuo account o sull'account del destinatario in parallelo. Mentre il tuo codice ha recuperato il tuo saldo e sta facendo il huge_overdraft_fees () e quant'altro, è del tutto possibile che qualche altro pagamento esegua lo stesso tipo di codice in parallelo. Recupereranno il tuo saldo (diciamo $ 100), faranno le loro transazioni (prendi i $ 20 che stai pagando e i $ 30 con cui ti stanno fregando), e ora entrambi i percorsi del codice hanno due saldi diversi: $ 80 e $ 70. A seconda di quale finisce per ultimo, ti ritroverai con uno di quei due saldi nel tuo account, invece dei $ 50 con cui avresti dovuto finire ($ 100 - $ 20 - $ 30). In questo caso, "errore bancario a tuo favore"

Ora, diciamo che usi i lucchetti. Il pagamento della bolletta ($ 20) colpisce per primo il tubo, quindi vince e blocca il record del tuo account. Ora hai un uso esclusivo e puoi detrarre i $ 20 dal saldo e riscrivere il nuovo saldo in pace ... e il tuo account finisce con $ 80 come previsto. Ma ... uhoh ... provi ad aggiornare l'account del destinatario, ed è bloccato, e bloccato più a lungo di quanto il codice permetta, facendo scadere la tua transazione ... Abbiamo a che fare con banche stupide, quindi invece di avere un errore corretto maneggiando, il codice tira semplicemente un exit()e i tuoi $ 20 svaniscono in uno sbuffo di elettroni. Ora sei fuori $ 20, e devi ancora $ 20 al ricevitore, e il tuo telefono viene recuperato.

Quindi ... inserisci le transazioni. Inizi una transazione, addebiti $ 20 sul tuo conto, provi ad accreditare $ 20 al destinatario ... e qualcosa esplode di nuovo. Ma questa volta, invece di exit(), il codice può semplicemente fare rollback, e puff, i tuoi $ 20 vengono aggiunti magicamente al tuo account.

Alla fine, si riduce a questo:

I blocchi impediscono a chiunque altro di interferire con i record del database con cui hai a che fare. Le transazioni impediscono a qualsiasi errore "successivo" di interferire con le cose "precedenti" che hai fatto. Nessuno dei due da solo può garantire che le cose vadano bene alla fine. Ma insieme lo fanno.

nella lezione di domani: The Joy of Deadlocks.

Vuoi una transazione SELECT ... FOR UPDATEo SELECT ... LOCK IN SHARE MODEall'interno di una transazione, come hai detto, poiché normalmente gli SELECT, indipendentemente dal fatto che siano in una transazione o meno, non bloccheranno una tabella. Quale sceglierai dipenderà dal fatto che tu voglia che altre transazioni siano in grado di leggere quella riga mentre la tua transazione è in corso.

http://dev.mysql.com/doc/refman/5.0/en/innodb-locking-reads.html

START TRANSACTION WITH CONSISTENT SNAPSHOTnon farà il trucco per te, poiché altre transazioni possono ancora arrivare e modificare quella riga. Questo è menzionato proprio nella parte superiore del collegamento sottostante.

Se altre sessioni aggiornano simultaneamente la stessa tabella, [...] potresti vedere la tabella in uno stato che non è mai esistito nel database.

http://dev.mysql.com/doc/refman/5.0/en/innodb-consistent-read.html

I concetti di transazione e i blocchi sono diversi. Tuttavia, la transazione utilizzava dei blocchi per aiutarla a seguire i principi ACID. Se vuoi che la tabella impedisca ad altri di leggere / scrivere nello stesso momento mentre sei in lettura / scrittura, hai bisogno di un blocco per farlo. Se vuoi assicurarti l'integrità e la coerenza dei dati, è meglio usare le transazioni. Penso concetti misti di livelli di isolamento nelle transazioni con blocchi. Cerca i livelli di isolamento delle transazioni, SERIALIZE dovrebbe essere il livello desiderato.

Ho avuto un problema simile durante il tentativo IF NOT EXISTS ...e l'esecuzione di uno INSERTche ha causato una condizione di competizione quando più thread stavano aggiornando la stessa tabella.

Ho trovato la soluzione al problema qui: Come scrivere le query INSERT IF NOT EXISTS in SQL standard

Mi rendo conto che questo non risponde direttamente alla tua domanda, ma lo stesso principio di eseguire un controllo e inserire come una singola dichiarazione è molto utile; dovresti essere in grado di modificarlo per eseguire l'aggiornamento.

Sei confuso con il blocco e la transazione. Sono due cose diverse in RMDB. Il blocco impedisce operazioni simultanee mentre la transazione si concentra sull'isolamento dei dati. Dai un'occhiata a questo fantastico articolo per i chiarimenti e qualche graziosa soluzione.

Userei un file

START TRANSACTION WITH CONSISTENT SNAPSHOT;

per cominciare, e a

COMMIT;

per finire con.

Tutto ciò che fai nel mezzo è isolato dagli altri utenti del tuo database se il tuo motore di archiviazione supporta le transazioni (che è InnoDB).