Re: [hibernate-dev] Wrapping of optimistic exceptions
Non-inline code such as this (this process occurs as part of transaction
handling) is difficult to always wrap. In general this requires
delegation to handle properly
(org.hibernate.proxy.EntityNotFoundDelegate e.g.)
Another idea (that requires a whole separate thread) would be to
consolidate native Hibernate and JPA codebases as we move into 5.0.
That would include exception hierarchies as much as possible.
On 11/09/2012 07:22 PM, Christian Bauer wrote:
I've noticed some cases where a native Hibernate exception is not
wrapped in a javax.persistence.OptimisticLockException.
EntityVerifyVersionProcess.java throws an org.hibernate.OptimisticLockException that is
passed on directly to JPA users.
EntityIncrementVersionProcess.java passes through the
org.hibernate.StaleObjectStateException from
AbstractEntityPersister#forceVersionIncrement() without wrapping. If wrapping in JPA
isn't possible, at least this one should be wrapped in an o.h.OptimisticLockException
for consistency sake.
Are JPA users expected to catch all three exceptions when using versioning? Is
OptimisticEntityLockException useful?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
steve(a)hibernate.org
http://hibernate.org