StaleObjectStateException vs OptimisticLockException

Question

Un'idea StaleObjectStateException viene lanciata nella mia app anziché OptimisticLockException (come ho letto che dovrei aspettarmelo) quando si verifica un problema di concorrenza ottimistico nella mia app. Non è necessario inserire il codice, poiché si tratta del problema di concorrenza più semplice: versione errata in una colonna timestamp.

Come si suppone che ottenga OptimisticLockException, non l'altro?

Answer 1

StaleObjectStateException viene generato quando si utilizza l'API di sospensione diretta. OptimisticLockException viene lanciata se si utilizza lo stile JPA in modalità ibernazione. Se questo ti confonde si prega di leggere: What's the difference between JPA and Hibernate?

Usa tenta blocco catch per intercettare l'eccezione:

try { 
    // your hibernate operation here 
} catch (OptimisticLockException e) { 
    // do something (eg: inform user update is conflicting) 
} 

Vale la pena notare OptimisticLockException verificarsi a causa di altra transazione ha aggiornato (da qui creato versione più recente) l'oggetto prima di ho la possibilità di farlo. In un'applicazione di interfaccia utente è normale chiedere all'utente se sovrascrivere/scartare/unire la sua versione dell'oggetto

Answer 2

A seguito della mia analisi di Hibernate 3.5.2 (ora bit vecchia), ho scoperto che a volte lanciavano OptimisticLockException e talvolta StaleObjectStateException. Le operazioni in serie lanciano anche StaleStateException, che è una superclasse di StaleObjectStateException, ma non hanno l'istanza di entità.

Mi sembra un refactoring incompleto, probabilmente è necessario prenderli entrambi e reagire allo stesso modo.