Il blocco ottimistico è una strategia in cui leggi un record, prendi nota di un numero di versione (altri metodi per farlo includono date, timestamp o checksum/hash) e controlli che la versione non sia cambiata prima di riscrivere il record. Quando riscrivi il record, filtri l'aggiornamento sulla versione per assicurarti che sia atomico. (cioè non è stato aggiornato tra quando controlli la versione e scrivi il record sul disco) e aggiorni la versione in un colpo.
Se il record è sporco (cioè una 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 prelevate da un pool e potresti non utilizzare la stessa connessione da un accesso all'altro.
Il blocco pessimistico è quando blocchi il record per tuo uso esclusivo fino a quando non hai finito con esso. Ha un'integrità molto migliore rispetto al blocco ottimistico, ma richiede di prestare attenzione alla progettazione dell'applicazione per evitare deadlock. Per utilizzare il blocco pessimistico è necessaria una connessione diretta al database (come sarebbe in genere il caso in un'applicazione server client a due livelli) 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 poi si riconnette utilizzando quell'ID. Il DBMS mantiene i blocchi e consente di eseguire il backup della sessione tramite il TxID. Ecco come funzionano le transazioni distribuite che utilizzano protocolli di commit a due fasi (come XA o COM+ Transactions).
