Sto ricercando alternative al blocco pessimistico a livello di database per ottenere l'isolamento della transazione in un cluster di Java di applicazioni che vanno contro lo stesso database. Sincronizzare l'accesso concorrente nel livello applicazione non è chiaramente una soluzione nella configurazione attuale poiché la stessa transazione del database può essere invocata da più JVM contemporaneamente. Al momento, siamo soggetti a occasionalmente race conditions che, a causa del optimistic locking che abbiamo in atto tramite Hibernate , causano un'eccezione StaleObjectStateException e una perdita di dati.
Ho una transazione moderatamente grande nell'ambito del mio progetto di refactoring. Descriviamolo come l'aggiornamento di una riga della tabella di livello superiore e quindi la creazione di vari inserti e / o aggiornamenti correlati a diverse delle sue entità figlio, ognuna delle quali è uno-a-molti. Vorrei assicurare un accesso esclusivo alla riga della tabella di livello superiore e tutti i bambini interessati, ma mi piacerebbe evitare il blocco pessimistico a livello di database per motivi di prestazioni.
Ha senso avviare una singola applicazione di coda messaggi (forse sincrona) in cui questo metodo potrebbe essere spostato per assicurare l'accesso sincronizzato rispetto a ciascun nodo del cluster usando il proprio, il che è un evidente rischio per le condizioni di gara? Sto menzionando questo approccio anche se non ne sono sicuro perché sia la riga della tabella di livello superiore che i suoi figli potrebbero essere aggiornati anche da altre chiamate di sistema, non solo dalla transazione menzionata. Quindi sto cercando di progettare una soluzione in cui la riga della tabella di livello superiore ei suoi figli saranno tutti in qualche modo pseudo-bloccati (isolamento esclusivo della transazione) ma a livello di applicazione e non di database.
Sono aperto a idee e suggerimenti, ho capito che questa non è una sfida molto semplice e secca.