Usi pratici del livello di Isolamento di Serializzazione?

Question

In quali scenari viene utilizzato il livello di isolamento SERIALIZZABILE? Ho visto alcune risposte sul sito Web che dice, quando vuoi che la transazione sia completamente isolata, di solito ci pensiamo noi.

Quello che mi piacerebbe sapere dalla tua esperienza è che, quando hai usato questo nei tuoi progetti/o hai visto questo per essere utilizzato in altri progetti e qual era il requisito specifico che non veniva soddisfatto da altri livelli di isolamento?

Answer 1

SERIALIZABLE è utile quando si creano report complessi che richiedono più query.

In READ COMMITTED o REPEATABLE READ le query potevano vedere le modifiche apportate tra la transazione avviata e il momento in cui sono state eseguite.

pg_dump, l'utilità PostgreSQL discarica, lo avvia lavoro con l'emissione di SET TRANSACTION ISOLATION LEVEL SERIALIZABLE, per garantire che lo stato del database di oggetto di dumping sarebbe quella del momento in cui il programma di utilità è stato eseguito, e le successive modifiche al database non poteva interferire con il discarica.

Answer 2

Le transazioni SERIALIZABLE sono utili se si desidera una semplice dimostrazione di correttezza nei carichi simultanei. Poiché la definizione del livello di isolamento della transazione serializzabile nello standard SQL (a partire da SQL-92) è che il comportamento di qualsiasi insieme simultaneo di transazioni serializzabili deve essere coerente con qualche ordine di esecuzione seriale (uno alla volta), qualsiasi transazione che può essere mostrata per fare la cosa giusta quando viene eseguita da sola, farà la cosa giusta come parte di qualsiasi combinazione di transazioni serializzabili.

C'è un costo per questa protezione - le transazioni devono essere bloccate o ripristinate per riprovare a volte per garantire l'isolamento della transazione serializzabile, e le informazioni devono essere tracciate per determinare quando è necessario intraprendere tali azioni. In alcuni ambienti di sviluppo, con un numero limitato di tipi di transazione e un numero limitato di sviluppatori, è spesso più conveniente utilizzare un livello di isolamento meno rigido e gestire le condizioni di gara in modo esplicito nel codice dell'applicazione. Una volta che decine di programmatori lavorano contro uno schema con centinaia di tabelle e decine di migliaia di tipi di transazione, il costo per determinare dove esistono le condizioni di competizione può diventare schiacciante a livelli di isolamento meno rigorosi e in genere diventa più conveniente utilizzare transazioni serializzabili .

Attualmente, il metodo più frequentemente attuato di fornire transazioni serializzabili è rigorosa bloccaggio a due fasi (S2PL), che si basa sul blocco blocchi mantenuti fino alla fine di ogni transazione, e deadlock rilevamento con rollbacks per rompere bloccaporte. Nei carichi con un conflitto di scrittura molto piccolo è possibile utilizzare il controllo della concorrenza ottimistico (OCC). Traccia un "read set" durante il corso della transazione e esegue il rollback se qualsiasi altra transazione modifica il read set. Alcuni prodotti di database si riferiscono all'isolamento degli snapshot come serializzabili, sebbene in realtà non forniscano le garanzie richieste dallo standard SQL. Una nuova tecnica denominata Serializable Snapshot Isolation (SerializableSI o SSI), è stata descritta per la prima volta in un documento accademico presentato al SIGMOD ACM 2008 e utilizzata in PostgreSQL versione 9.1 e successive. Utilizza l'isolamento dell'istantanea più il tracciamento dei modelli di dipendenza in lettura/scrittura per determinare quando una transazione deve essere annullata. Esistono altre tecniche che sono viste meno spesso nella produzione. Ognuno di questi ha il proprio insieme di vantaggi e svantaggi, fornendo un punto di pareggio diverso per una domanda come questa.