Ottimismo vs. blocco pessimistico

Question

Comprendo le differenze tra blocco ottimistico e pessimistico. Ora qualcuno potrebbe spiegarmi quando userei uno dei due in generale?

E la risposta a questa domanda cambia a seconda che io stia usando o meno una procedura memorizzata per eseguire la query?

Ma solo per controllare, mezzi ottimisti " non bloccare la tabella durante la lettura " e mezzi pessimistici " bloccare la tabella durante la lettura. "

Answer 1

Blocco ottimistico è una strategia in cui leggi un record, prendi nota di un numero di versione ( altri metodi per fare ciò includono date, timestamp o checksum / hash) e verificare che la versione non sia cambiata prima di riscrivere il record. Quando si riscrive il record, si filtra l'aggiornamento sulla versione per assicurarsi che sia atomico. (ovvero non è stato aggiornato tra quando si controlla la versione e si scrive il record sul disco) e si aggiorna la versione in un colpo solo.

Se il record è sporco (ovvero versione diversa dalla tua), interrompi la transazione e l'utente può riavviarla.

Questa strategia è più applicabile ai sistemi ad alto volume e alle architetture a tre livelli in cui non si mantiene necessariamente una connessione al database per la sessione. In questa situazione il client non può effettivamente mantenere i blocchi del database poiché le connessioni vengono prese da un pool e potresti non utilizzare la stessa connessione da un accesso al successivo.

Blocco pessimistico è quando blocchi il record per il tuo uso esclusivo fino a quando non hai finito con esso. Ha un'integrità molto migliore del blocco ottimistico, ma richiede di fare attenzione con il design dell'applicazione per evitare Deadlocks . Per utilizzare il blocco pessimistico è necessaria una connessione diretta al database (come in genere accade in un due server client di livello ) o un ID transazione disponibile esternamente che può essere utilizzato indipendentemente dalla connessione.

In quest'ultimo caso si apre la transazione con il TxID e quindi si riconnette utilizzando tale ID. Il DBMS mantiene i blocchi e consente di riprendere il backup della sessione tramite TxID. Ecco come le transazioni distribuite utilizzano protocolli di commit a due fasi (come XA o < a href = "http://msdn.microsoft.com/en-us/library/ms687120(VS.85).aspx" rel = "noreferrer"> COM + Transactions ) funziona.

Answer 2

Il blocco ottimistico viene utilizzato quando non si prevedono molte collisioni. Costa meno per fare una normale operazione ma se si verifica la collisione pagheresti un prezzo più alto per risolverlo quando la transazione viene interrotta.

Il blocco pessimistico viene utilizzato quando è prevista una collisione. Le transazioni che violerebbero la sincronizzazione sono semplicemente bloccate.

Per selezionare il meccanismo di blocco corretto, è necessario stimare la quantità di letture e scritture e pianificare di conseguenza.

Answer 3

L'ottimista presume che nulla cambierà mentre lo stai leggendo.

Il pessimista presume che qualcosa lo farà e quindi lo blocca.

Se non è essenziale che i dati vengano letti perfettamente, usa l'ottimismo. Potresti ottenere la strana lettura "sporca", ma è molto meno probabile che si traduca in deadlock e simili.

La maggior parte delle applicazioni Web va bene con letture sporche: in rare occasioni i dati non corrispondono esattamente al ricaricamento successivo.

Per operazioni esatte sui dati (come in molte transazioni finanziarie) utilizzare pessimisti. È essenziale che i dati vengano letti in modo accurato, senza modifiche non mostrate: ne vale la pena l'overhead di blocco aggiuntivo.

Oh, e il server Microsoft SQL per impostazione predefinita è il blocco della pagina - fondamentalmente la riga che stai leggendo e alcuni lati. Il blocco delle file è più preciso ma molto più lento. Spesso vale la pena impostare le transazioni su read-commit o no-lock per evitare deadlock durante la lettura.

Answer 4

Oltre a quanto già detto, va detto che il blocco ottimistico tende a migliorare la concorrenza a spese della prevedibilità. Il blocco pessimistico tende a ridurre la concorrenza, ma è più prevedibile.

Paghi i tuoi soldi, ecc.

Answer 5

Penserei a un altro caso in cui il blocco pessimistico sarebbe una scelta migliore.

Per un blocco ottimistico ogni partecipante alla modifica dei dati deve accettare di utilizzare questo tipo di blocco. Ma se qualcuno modifica i dati senza preoccuparsi della colonna della versione, ciò rovinerà l'intera idea del blocco ottimistico.

Answer 6

Esistono sostanzialmente due risposte più popolari. Il il primo dice sostanzialmente

  

L'ottimismo richiede architetture a tre livelli in cui non si mantiene necessariamente una connessione al database per la sessione, mentre il blocco pessimistico è quando si blocca il record per uso esclusivo fino a quando non si è finito con esso. Ha un'integrità molto migliore rispetto al blocco ottimistico, è necessaria una connessione diretta al database.

Un'altra risposta è

  

ottimistico (versioning) è più veloce a causa della mancanza di blocchi ma il blocco (pessimistico) funziona meglio quando la contesa è elevata ed è meglio prevenire il lavoro piuttosto che scartarlo e ricominciare da capo.

o

  

Il blocco ottimistico funziona al meglio in caso di collisioni rare

Come viene inserito in questa pagina.

Ho creato la mia risposta per spiegare come " mantenere la connessione " è correlato a "basse collisioni".

Per capire quale strategia è la migliore per te, non pensare alle Transazioni al secondo del tuo DB ma alla durata di una singola transazione. Normalmente, si apre trasnaction, si esegue un'operazione e si chiude la transazione. Questa è una transazione classica, breve, che ANSI aveva in mente e che andava bene per evitare di bloccare. Ma come si implementa un sistema di prenotazione dei biglietti in cui molti clienti prenotano le stesse stanze / posti allo stesso tempo?

Sfoglia le offerte, compila il modulo con molte opzioni disponibili e prezzi correnti. Ci vuole molto tempo e le opzioni possono diventare obsolete, tutti i prezzi non validi tra voi hanno iniziato a compilare il modulo e premere " Accetto " perché non c'era nessun blocco sui dati a cui hai avuto accesso e qualcun altro, più agile, ha interferito modificando tutti i prezzi e devi ricominciare con nuovi prezzi.

Puoi invece bloccare tutte le opzioni mentre le leggi. Questo è uno scenario pessimistico. Vedi perché fa schifo. Il tuo sistema può essere abbattuto da un singolo pagliaccio che semplicemente avvia una prenotazione e va a fumare. Nessuno può prenotare nulla prima che finisca. Il flusso di cassa scende a zero. Questo è il motivo per cui le riserve ottimistiche sono utilizzate nella realtà. Coloro che si dilettano troppo a lungo devono riavviare la prenotazione a prezzi più alti.

In questo approccio ottimista devi registrare tutti i dati che leggi (come in mia lettura ripetuta ) e vieni al punto di commit con la tua versione dei dati (desidero acquistare azioni al prezzo visualizzato in questo preventivo, non al prezzo corrente). A questo punto, viene creata la transazione ANSI, che blocca il DB, controlla se non viene modificato nulla e commette / interrompe l'operazione. IMO, questa è un'emulazione efficace di MVCC , che è anche associato a Optimistic CC e presume anche che il tuo la transazione si riavvia in caso di interruzione, ovvero effettuerai una nuova prenotazione. Una transazione qui implica decisioni di un utente umano.

Sono lungi dal comprendere come implementare manualmente MVCC ma penso che le transazioni di lunga durata con l'opzione di riavvio siano la chiave per comprendere l'argomento. Correggimi se sbaglio ovunque. La mia risposta è stata motivata da questo Alex Kuznecov capitolo .

Answer 7

Nella maggior parte dei casi, il blocco ottimistico è più efficiente e offre prestazioni più elevate. Quando si sceglie tra blocco pessimistico e ottimistico, considerare quanto segue:

• Il blocco pessimistico è utile se ci sono molti aggiornamenti e possibilità relativamente elevate di utenti che provano ad aggiornare i dati contemporaneamente tempo. Ad esempio, se ogni operazione può aggiornare un gran numero di record alla volta (la banca potrebbe aggiungere gli interessi attivi a tutti account alla fine di ogni mese) e due applicazioni sono in esecuzione tali operazioni allo stesso tempo, avranno conflitti.

• Il blocco pessimistico è anche più appropriato nelle applicazioni che contengono tabelle di piccole dimensioni che vengono frequentemente aggiornate. Nel caso di questi cosiddetti hotspot, i conflitti sono così probabili che il blocco ottimistico spreca sforzo nel rollback delle transazioni in conflitto.

• Il blocco ottimistico è utile se la possibilità di conflitti è molto elevata basso & # 8211; ci sono molti record, ma relativamente pochi utenti o pochissimi aggiornamenti e principalmente operazioni di tipo read.

Answer 8

Un caso d'uso per il blocco ottimistico è che l'applicazione utilizzi il database per consentire a uno dei thread / host di "rivendicare" un'attività. Questa è una tecnica che mi è tornata utile su base regolare.

Il miglior esempio che mi viene in mente è per una coda di attività implementata utilizzando un database, con più thread che rivendicano attività contemporaneamente. Se un'attività ha lo stato 'Disponibile', 'Rivendicato', 'Completato', una query db può dire qualcosa come " Set status = 'Reclamato' dove status = 'Disponibile'. Se più thread tentano di modificare lo stato in questo modo, tutti tranne il primo non riusciranno a causa di dati sporchi.

Si noti che questo è un caso d'uso che coinvolge solo il blocco ottimistico. Quindi, in alternativa al dire "Blocco ottimistico viene utilizzato quando non ci si aspettano molte collisioni", può anche essere usato dove ci si aspetta collisioni ma si desidera che esista esattamente una transazione.