database - guide - Livello di isolamento vs Ottimizzazione Lock-Hibernate, JPA




orm hibernate (2)

Ho un'applicazione web in cui voglio garantire la concorrenza con un blocco del livello di DB sull'oggetto che sto tentando di aggiornare. Voglio assicurarmi che una modifica in batch o un altro utente o processo non possano finire per introdurre incoerenze nel DB.

Vedo che i livelli di isolamento garantiscono coerenza di lettura e blocco ottimistico con il campo @Version grado di garantire che i dati @Version scritti con uno stato coerente.

La mia domanda è: non possiamo garantire la coerenza solo con il livello di isolamento? Effettuando la mia transazione che aggiorna il record Serializable (non considerando la performance), non garantirò che un blocco appropriato venga preso dalla transazione e qualsiasi altra transazione che tenta di aggiornare o acquisire il lock o questa transazione fallirà? Ho davvero bisogno di una versione o di una gestione di timestamp per questo?


A meno che non stiamo parlando di una piccola applicazione web isolata (solo l'app che sta lavorando su un database), quindi rendere tutte le tue transazioni Serializable significherebbe avere molta fiducia nel tuo progetto, non tenendo conto del fatto che potrebbe non essere l'unica applicazione che colpisce su quel determinato database.

A mio parere, l'incorporazione del livello di isolamento Serializable, o di un Blocco Pessimistico in altre parole, dovrebbe essere molto buona se presa e richiesta per:

  • Grandi database e transazioni brevi che aggiornano solo poche righe
  • Dove la possibilità che due transazioni simultanee modifichino le stesse righe è relativamente bassa.
  • Dove le transazioni relativamente lunghe sono principalmente di sola lettura.

In base alla mia esperienza, nella maggior parte dei casi l'utilizzo del solo blocco ottimistico sarebbe la decisione più vantaggiosa, in quanto frequenti modifiche simultanee si verificano soprattutto in una piccola percentuale di casi. Il blocco ottimistico aiuta anche altre applicazioni a correre più velocemente (non pensare solo a te stesso!).

Quindi, quando prendiamo lo spettro delle strategie di blocco pessimistico-ottimista, a mio parere la verità sta in qualche luogo più verso il bloccaggio ottimistico con un sapore di serializzabile qua e là.

Non riesco davvero a fare riferimento a nulla qui poiché la risposta è basata sulla mia esperienza personale con molti progetti Web complessi e dai miei appunti quando stavo preapring al mio certificato JPA.

Spero possa aiutare.


A seconda del livello di isolamento che hai scelto, la risorsa specifica verrà bloccata fino al commit o al rollback della transazione dato - può essere bloccata su un'intera tabella, riga o blocco di sql. È un blocco pessimistico ed è garantito a livello di database durante l'esecuzione di una transazione.

Il blocco ottimistico d'altra parte presuppone che più transazioni raramente interferiscano l'una con l'altra, quindi non è richiesto alcun blocco in questo approccio. È un controllo sul lato dell'applicazione che utilizza @Version attributo @Version per stabilire se la versione di un record è cambiata tra il recupero e il tentativo di aggiornarlo.

È ragionevole utilizzare un approccio di blocco ottimistico nelle applicazioni Web poiché la maggior parte delle operazioni si estende attraverso più richieste HTTP. Solitamente si recuperano alcune informazioni dal database in una richiesta e si aggiornano in un'altra. Sarebbe molto costoso e poco saggio mantenere aperte le transazioni con il blocco delle risorse del database a lungo. Ecco perché supponiamo che nessuno utilizzi la serie di dati su cui stiamo lavorando: è più economico. Se l'ipotesi è errata e la versione è cambiata tra le richieste di qualcun altro, Hibernate non aggiornerà la riga e genererà OptimisticLockingException . Come sviluppatore, sei responsabile della gestione di questa situazione.

Semplice esempio Servizio di aste online: stai guardando una pagina di articoli. Leggi la sua descrizione e le specifiche. Tutto ciò richiede, diciamo, 5 minuti. Con il blocco pessimistico e alcuni livelli di isolamento, bloccherai altri utenti da questa particolare pagina oggetto (o anche da tutti gli elementi!). Con un blocco ottimistico tutti possono accedervi. Dopo aver letto l'articolo sei disposto a fare un'offerta, quindi fai clic sul pulsante corretto. Se un altro utente guarda questo articolo e ne modifica il suo stato (il proprietario ha cambiato la sua descrizione, un'altra offerta su di esso) nel frattempo probabilmente (a seconda dell'implementazione dell'app) verrà informato sulle modifiche prima che l'applicazione accetti l'offerta perché la versione è 'ho ottenuto non è la stessa versione persistente nel database.

Spero che chiarisca alcune cose per te.





orm