This content has been marked as final.
Show 4 replies
-
1. Re: Handling a transaction rollback
gonorrhea Jun 15, 2009 10:12 PM (in response to lobz)Are you using EJB 3 (CMT/BMT) or Seam-managed tx's?
-
2. Re: Handling a transaction rollback
lobz Jun 16, 2009 9:16 AM (in response to lobz)The latter, seam-managed transactions.
-
3. Re: Handling a transaction rollback
allforjava.allforjava.aol.in Jul 16, 2009 4:15 PM (in response to lobz)Facing similar problem. http://www.seamframework.org/Community/WhyOrghibernateLazyInitializationExceptionOnRollback
Please assist. Thank you in advance.
Note: I guess using SMPC and related transactions annotated with @Transactional.
-
4. Re: Handling a transaction rollback
jeanluc Jul 16, 2009 7:16 PM (in response to lobz)Quoting from the JPA spec, 3.3.2 Transaction Rollback
For both transaction-scoped and extended persistence contexts, transaction rollback causes all pre-existing managed instances and removed instances to become detached. The instances’ state will be the state of the instances at the point at which the transaction was rolled back. Transaction rollback typically causes the persistence context to be in an inconsistent state at the point of rollback. In particular, the state of version attributes and generated state (e.g., generated primary keys) may be inconsistent. Instances that were formerly managed by the persistence context (including new instances that were made persistent in that transaction) may therefore not be reusable in the same manner as other detached objects—for example, they may fail when passed to the merge operation.If you get a rollback, it very much depends why it happened. Unless you try to discover the root cause, it's better to discard all data.