Non ibernare un blocco ottimistico di default per gli oggetti unifamiliari?

Question

Ho un'applicazione che fa:

void deleteObj(id){
    MyObj obj = getObjById(id);
    if (obj == null) {
        throw new CustomException("doesn't exists");
    }
    em.remove(obj);//em is a javax.persistence.EntityManager
}

non ho esplicitamente configurare ottimista bloccaggio con la versione field.However, se due di richiesta sono in esecuzione in parallelo, cercando di eliminare lo stesso oggetto, allora ottengo a volte un HibernateOptimisticLockingFailureException e altre volte il "CustomException".

E 'normale per ottenere HibernateOptimisticLockingFailureException senza impostare esplicitamente il blocco ottimistico? Non ibernare un blocco ottimistico di default per gli oggetti unifamiliari?

Che cosa stai facendo per gestire questo HibernateOptimisticLockingFailureException? Riprova o informare l'utente con un messaggio predefinito come "server occupato"?

Answer 1

Prima di tutto, HibernateOptimisticLockingFailureException è il risultato di meccanismo di persistenza traduzione eccezione di primavera. E 'gettato in risposta a StaleStateException , la cui javadoc dice:

  

generata quando un numero di versione o timestamp di controllo non è riuscita, che indica che la sessione conteneva dati non aggiornati (quando si utilizzano le transazioni lunghe con versioning). Inoltre si verifica se proviamo eliminare o aggiornare una riga che non esiste.

Dal senso comune, ad eccezione di blocco ottimistico si verifica quando di modifica dei dati restituisce il numero inatteso di righe coinvolte. Essa può essere causata da non corrispondente valore di versione nonché dall'assenza della fila affatto.

Per fare in modo che entità è stato effettivamente rimosso si può provare a lavare il contesto da em.flush() subito dopo la rimozione e catturare un'eccezione lanciata da essa (si noti che dovrebbe essere sottoclasse di PersistenceException avere StaleStateException come una causa).