letture non impegnate?

Question

Stavo esaminando potenziali problemi di concorrenza nel DB, quindi sono andato a documentarmi.ho trovato http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005267.htm e menziona l'accesso ai dati non impegnati.

Accesso ai dati non impegnati.L'applicazione A potrebbe aggiornare un valore nel database e l'applicazione B potrebbe leggere quel valore prima che fosse impegnato.Quindi, se il valore di A non viene successivamente impegnato, ma indicato, i calcoli eseguiti da B si basano su dati non impegnati (e presumibilmente non validi).

Che cosa...pensavo che altre sessioni (stessa app e anche stesso thread) potessero leggere i dati che non sono stati ancora impegnati?Pensavo che solo la connessione/sessione (non sono sicuro della mia terminologia) che ha scritto i dati nella transazione non impegnata potesse leggere i dati non impegnati.

Gli altri thread possono davvero leggere i dati che non sono stati impegnati?Ho intenzione di usare mysql ma potrei usare sqlite

Answer 1

Ciò che possono leggere le altre sessioni dipende da come hai impostato il tuo database.In MySQL dipende anche dal motore di database utilizzato.Il termine che stai cercando (in termini ANSI SQL) è "livello di isolamento".

Molti database utilizzeranno per impostazione predefinita un livello di isolamento in cui le letture sui dati non salvati verranno bloccate.Pertanto, se la transazione A aggiorna il record 1234 nella tabella T e quindi la transazione B tenta di selezionare il record 1234 prima che A esegua il commit o il rollback, B si bloccherà finché A non esegue una di queste cose.

Vedere Transazioni MySQL, Parte II - Livelli di isolamento delle transazioni.

Uno svantaggio serio di ciò è che le operazioni di aggiornamento batch che risiedono in transazioni di lunga durata (in genere) possono potenzialmente bloccare molte richieste.

Puoi anche impostarlo in modo che B veda i dati non impegnati, ma questo è spesso sconsiderato.

In alternativa puoi utilizzare uno schema chiamato MVCC ("Controllo della concorrenza multiversione"), che fornirà a diverse transazioni una visione coerente dei dati in base all'ora di inizio della transazione.Ciò evita il problema della lettura senza commit (lettura di dati che potrebbero essere sottoposti a rollback) ed è molto più scalabile, soprattutto nel contesto di transazioni di lunga durata.

MySQL supporta MVCC.

Answer 2

Certamente in SQL Server si può, si deve scegliere di farlo, non è il default, ma se si utilizza il livello di isolamento destra o hint di query si può scegliere di leggere una riga uncommitted, questo può porta a problemi e anche una doppia lettura della stessa riga in teoria.

Answer 3

Questo articolo cita l'accesso ai dati non impegnati come uno dei problemi eliminato da parte del gestore di database.

  

I controlli database manager questo   accedere ad evitare effetti indesiderati,   come ad esempio:

     

...

     

  
• L'accesso ai dati non impegnati.
  

motore di storage InnoDB MySQL supporta diversi livelli di isolamento delle transazioni. Per dettagli, vedere http://dev.mysql.com/doc/refman/ 5.4 / it / set-transaction.html .

Answer 4

Per alcune versioni di alcuni database, impostando le query di essere in grado di leggere non impegnati migliorerà le prestazioni, a causa della chiusura ridotta. Che lascia ancora questioni di sicurezza, affidabilità e scalabilità a cui rispondere.

Per dare una specifica, che ho usato per lavorare su un grande sito di e-commerce. Hanno usato leggono impegnati sulla legge al catalogo del negozio, dal momento che i dati sono stati pesantemente accesso, modificati di rado, e non sensibile alle preoccupazioni per la lettura dei dati non impegnati. Tutti i dati del catalogo che è stato utilizzato per effettuare un ordine sarebbero nuovamente verificati in ogni caso. Questo è stato in SQL Server 2000, che è stato conosciuto per avere problemi di prestazioni di bloccaggio. Nelle versioni più recenti di SQL Server, le prestazioni di chiusura è migliorata, quindi questo non sarebbe necessario.