3 Replies Latest reply on Nov 3, 2014 6:55 AM by mkouba

    Events processed in reverse order from how they were fired during a transaction

    joshuak
    joshuak Oct 31, 2014 2:54 PM

      Hello again,

       

      During the course of a transaction, I have several different events fired representing the lifecycle of some entity or entities. As expected, the IN_PROGRESS transactional observers are immediately processed for a given event. Also as expected, the AFTER_SUCCESS, etc. observers are registered with JTA to be processed after the transaction is complete. What is not expected is the order in which the events themselves are processed after the transaction completes. Note that I am NOT referring to the processing order of observers for any specific event, as I know this ordering is not guaranteed by the spec.

       

      The snippet below is a section of my log (anonymized with internal package names removed) that is a clear example of this issue.

      2014-10-31 17:51:18,801 FINEST [DAO.fireEvent] (default task-102) Fired event EntityType1 with id 1 fired with qualifiers [@Created()]

      2014-10-31 17:51:18,803 FINEST [EntityFired.inProgress] (default task-102) Observed event EntityType1 with id 1 fired with qualifiers [@javax.enterprise.inject.Any(), @Created()]

      2014-10-31 17:51:18,873 FINEST [DAO.fireEvent] (default task-102) Fired event EntityType2 with id 1 fired with qualifiers [@Created()]

      2014-10-31 17:51:18,875 FINEST [EntityFired.inProgress] (default task-102) Observed event EntityType2 with id 1 fired with qualifiers [@javax.enterprise.inject.Any(), @Created()]

      2014-10-31 17:51:18,890 FINEST [EntityFired.afterSuccess] (default task-102) Observed event EntityType2 with id 1 fired with qualifiers [@javax.enterprise.inject.Any(), @Created()]

      2014-10-31 17:51:18,918 FINEST [EntityFired.afterSuccess] (default task-102) Observed event EntityType1 with id 1 fired with qualifiers [@javax.enterprise.inject.Any(), @Created()]

       

      My questions are: Is this intended? Is this just a side-effect of the way JTA handles Synchronizations? Is there some configuration I can change to ensure that events are fired in the same order after the transaction as they were fired during it?

       

      EDIT


      I've found some additional information that seems to suggest that Synchronizations themselves are not ordered.

       

      Re: new requirement for synchronization ordering (WildFly is delisting resources during Sychronization.beforeCompletion)

      [JBTM-2259] Allow the ordering of some synchronizations to be configurable  - JBoss Issue Tracker

       

      As per the spec (10.5. Observer notification), CDI uses Synchronizations to register the after completion observers, so could this be directly related to my issue?

      • 246 Views
      • Tags:
        • 1. Re: Events processed in reverse order from how they were fired during a transaction
          mkouba
          mkouba Nov 3, 2014 4:43 AM (in response to joshuak)

          Hi joshuak,

          Yes, it seems related. Weld (1.1.x, 2.x) registers one JTA Synchronization per one transactional observer method. And since the ordering of Synchronizations is not guaranteed there's nothing we can do on the Weld side.

            • Actions
          • 2. Re: Events processed in reverse order from how they were fired during a transaction
            joshuak
            joshuak Nov 3, 2014 5:32 AM (in response to mkouba)

            Martin Kouba wrote:

             

            Hi joshuak,

            Yes, it seems related. Weld (1.1.x, 2.x) registers one JTA Synchronization per one transactional observer method. And since the ordering of Synchronizations is not guaranteed there's nothing we can do on the Weld side.

             

            Martin,

            After reading through the links I posted, I found a suggestion to implement ordering with Synchronizations and was wondering if it was possible to implement it this way in Weld. The suggestion in its simplest form was: Register a single Synchronization that then takes care of the individual elements that need to be ordered instead of registering said elements individually.

             

            I won't pretend to understand the complexity of Weld or its interactions with other Java EE components, but I thought I'd ask about this because 1) Its honestly somewhat annoying, 2) Current Weld 3.x development is starting to add ordering for observers themselves, and I expect those that care about the ordering of observers might care about the ordering of events as well.

             

            Also, you specifically pointed out Weld 1.1.x and 2.x. In 3.x will this mechanism have a different implementation?

             

            Thanks again for your help.

              • Actions
            • 3. Re: Events processed in reverse order from how they were fired during a transaction
              mkouba
              mkouba Nov 3, 2014 6:55 AM (in response to joshuak)
              Also, you specifically pointed out Weld 1.1.x and 2.x. In 3.x will this mechanism have a different implementation?

              Yes, in Weld 3.x only one Synchronization is registered in order to support events ordering (see also https://issues.jboss.org/browse/WELD-1728 and https://issues.jboss.org/browse/CDI-4). However, I'm not sure whether we can backport this into 2.2.x considering backwards compatibility.

                • Actions