4 Replies Latest reply on Jul 16, 2009 7:16 PM by jeanluc

    Handling a transaction rollback

    lobz

      Hi!


      The problem is the following:
      - I start a conversation
      - create/modify some entities (usually through EntityHome beans) and then persist it
      - get some error from the database, the transaction gets rolled back


      How should I handle this situation? I display the error message on the client but when the user clicks the save button again, I get some errors 'like entity not managed', 'detached entity passed to persist'.


      Do I have to call something like this?


      home.setInstance(entityManager.merge(home.getInstance()))



      Or/and perhaps set the new entity's ID back to 0 if the operation was a persist?
      And what should I do with the entity's collections?

        • 1. Re: Handling a transaction rollback
          gonorrhea

          Are you using EJB 3 (CMT/BMT) or Seam-managed tx's?

          • 2. Re: Handling a transaction rollback
            lobz

            The latter, seam-managed transactions.

            • 3. Re: Handling a transaction rollback
              allforjava.allforjava.aol.in

              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

                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.