Details

    • Type: Bug
    • Status: Closed
    • Priority: Critical
    • Resolution: Won't Fix
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None

      Description

      It seams that @AfterCommit does not value 'nested' behaviour. This would introduce awefull runtime problems in data consistency if used that way. I reviewed some code lately and found places where this transactional behaviour has to be considered a critical bug in this application. Can you please confirm, that these assumptions are right or wrong and also provide a better way to handle transactional behaviour?

      (from emaillist)

      The problem I have seams within the documentation. For @CommitAfter the documentation states that the transaction is committed at the end of the method.

      Therefore I think that for the case:
      @CommitAfter
      a()

      {...}

      @CommitAfter
      b()

      { a(); }

      At least two commits will happen for each of those methods. Am I right here?

      There is the PersistanceContext annotation and that somehow I can use it to control transactional behaviour but In my opinion this focus about using a second session for two different persistent contexts. Am I right on this one?

      So in the end it looks like programming or using some other sort of mechanism that is aware of nested logical transactions and ignores the commit inside an ongoing transaction. This behavior can be introduced using HibernateSessionManager.

      There is also this post http://tawus.wordpress.com/2011/04/23/tapestry-magic-5-advising-services/ which describes exactly what I need.

      The question here is there anything shipped with tapestry that allows this kind of behavior or am I missunderstanding @CommitAfter and this behavior is already present?

      Is there a standard way to control whether there is a ReadOnly transaction going on or not? I did not found anything about it. Maybe I am blind.

        Activity

        Hide
        martinkersten Martin Kersten added a comment -

        Better version to solve this:

        public void advise(final MethodInvocation invocation)
        {
        final EntityTransaction transaction = getTransaction();

        boolean isNested = false; //<-- Change

        if (transaction != null && !transaction.isActive())

        { transaction.begin(); }

        else
        isNested = true; //<-- Change

        try

        { invocation.proceed(); }

        catch (final RuntimeException e)
        {
        if (transaction != null && transaction.isActive() && !isNested) //<-- Change

        { rollbackTransaction(transaction); }

        throw e;
        }

        // Success or checked exception:

        if (transaction != null && transaction.isActive() && !isNested) //<-- Change

        { transaction.commit(); }

        }

        This way, the AfterCommitAdvisor does not commit or rollback if there is a transaction already being in progress. So nesting service methods annotated with @AfterCommit will work as intended and do not create two or more transactions when being nested.

        Show
        martinkersten Martin Kersten added a comment - Better version to solve this: public void advise(final MethodInvocation invocation) { final EntityTransaction transaction = getTransaction(); boolean isNested = false; //<-- Change if (transaction != null && !transaction.isActive()) { transaction.begin(); } else isNested = true; //<-- Change try { invocation.proceed(); } catch (final RuntimeException e) { if (transaction != null && transaction.isActive() && !isNested) //<-- Change { rollbackTransaction(transaction); } throw e; } // Success or checked exception: if (transaction != null && transaction.isActive() && !isNested) //<-- Change { transaction.commit(); } } This way, the AfterCommitAdvisor does not commit or rollback if there is a transaction already being in progress. So nesting service methods annotated with @AfterCommit will work as intended and do not create two or more transactions when being nested.
        Hide
        martinkersten Martin Kersten added a comment -

        Never mind... .

        Show
        martinkersten Martin Kersten added a comment - Never mind... .

          People

          • Assignee:
            Unassigned
            Reporter:
            martinkersten Martin Kersten
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Time Tracking

              Estimated:
              Original Estimate - 4h
              4h
              Remaining:
              Remaining Estimate - 4h
              4h
              Logged:
              Time Spent - Not Specified
              Not Specified

                Development