This content has been marked as final.
Show 4 replies
-
1. Re: Handling a transaction rollback
Arbi Sookazian Jun 15, 2009 10:12 PM (in response to Robert Raksi)Are you using EJB 3 (CMT/BMT) or Seam-managed tx's?
-
2. Re: Handling a transaction rollback
Robert Raksi Jun 16, 2009 9:16 AM (in response to Robert Raksi)The latter, seam-managed transactions.
-
3. Re: Handling a transaction rollback
Prathamesh Gaddam Jul 16, 2009 4:15 PM (in response to Robert Raksi)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
Jean Luc Jul 16, 2009 7:16 PM (in response to Robert Raksi)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.