Hibernate (APP): come gestire StaleObjectStateException quando più oggetto è stato modificato e impegnato

Question

Si consideri lo scenario: Una Db transazione envolving più di una riga da diverse tabelle con il controllo delle versioni.

Ad esempio: A shopLists e prodotti. Qualora uno Shoplist può contenere prodotti (con la loro quantità nel shoplist) ed i prodotti hanno il loro stock attuale.

Quando inserisco ou modificare uno Shoplist, voglio che lo stock di tali prodotti nella Shoplist essere aggiornato per mantenere lo stock consistente.

Per fare questo, ho aperto una transazione, inserimento / aggiornamento del Shoplist, aggiornare le scorte per ogni prodotto (a triangolo) e quindi il commit della transazione. Nessun grosso problema fino ad ora.

Tuttavia, un altro utente potrebbe aver aggiornato uno o più prodotti in comune. O anche aggiornato lo Shoplist stesso. In entrambi i casi, vorrei avere uno StaleObjectStateException quando commettere la transazione.

La domanda è:? C'è un modo per determinare quale tabella causato lo StaleObjectStateException

Nel caso in cui il prodotto ha causato l'eccezione, ho potuto aggiornare tutti i prodotti envolved dal DB e quindi riapplicare l'azionari delta. E va bene. Nel caso in cui lo Shoplist ha causato l'eccezione, sarebbe meglio semplicemente segnalare il problema per l'utente in modo da poter ricominciare da capo.

Grazie molto per il vostro aiuto.

Answer 1

I found out how.

First things first: the JPA (or the hibernate itself) wraps the org.hibernate.StaleObjectStateException exception as javax.persistence.OptimisticLockException. So, if you want to catch the right exception, go for OptimisticLockException.

Second: The hibernate will only throw the OptimisticLockException when you call EntityManager's method Flush before commit. If you call Commit directly you will get another exception instead (I've forgot which). Considering almost everyone catches those exceptions issued by the commit method and go for a transaction rollback, you'll get a Rollback's related exception (can't remember which once again).

Third and finaly answering my original question: You just have to call the getEntity method from the OptimisticLockException instance to get the origin of the Versioning error. That's going to provide you anything you need related to that.

Thanks for all of those who passed by here. Any questions regarding that, just ask and I'll be glad to help.