3 Replies Latest reply on Apr 11, 2012 10:14 AM by dfisher95350

    Trouble migrating Envers 3.6 application from JBoss 4.x to 7.1

    dfisher95350

      We have a WAR that includes Hibernate 3.6.0 JARs. When we deploy it to JBoss 7.1, the application stops writing records to our Envers-configured audit tables, including the hub Revision table. We extend Envers AuditEventListener in order to write extra details to our Revision records. It works, meaning it fires, for example onPostUpdate(). In onPostUpdate(), et al., we use AuditReaderFactory to get an AuditReader and getCurrentRevision() and write extra data to it. Normally we use the argument persist=false when we do this, and let it persist later. (As a matter of present experimentation, I have used persist=true, and it does persist to the Revision table, but ....) While the AuditEventListener does get notified of the changed Entity, and while all the participants to this point (i.e. Envers, Hibernate) seem to recognize that the Entity is dirty/changed, the [Enitity name]_AUDIT table is never written to. And unless I force the write of the Revision record (with persist=true) it is never written either. So ... I am guessing that the order of events is something like this:

       

      1. The Envers listener is notified that Entity X has changed.

      2. We retrieve and enhance our currentRevision.

      3. Changes to Entity X are persisted.

      4. Envers, notified that the Session is closing out and it's time to commit, re-obtains a/the currentRevision.

      5. At this point it finds NO changed entities in the Session, so it doesn't bother to persist currentRevision.

       

      To be clear, #4 and #5 are hypothetical. I don't know yet that they describe what is actually happening. My hypothesis based on the behavior and my reading of Envers documentation is that somehow, between #3 and #4, the Envers state evaluation switches from hasChanges=true to hasChanges=false.

       

      We've tried excluding any implicit imports of 4.x Hibernate classes using <jboss-deployment-structure/>, and while at first we thought this was a good lead, we don't believ now that it is the problem. Presently we are leaning towards guessing that there is different transactional behavior in the JBoss 7 transaction manager, such that it causes different commit behavior at our Service boundary (configured with Spring AOP tx:, not EJB).

       

      Any suggestions, hints welcome.

       

      Thanks.

        • 1. Re: Trouble migrating Envers 3.6 application from JBoss 4.x to 7.1
          vatsanm

          I dont knwo if this helps pr makes it worse, but here it is.

           

          I had transactional issues when I mised the hibrenate transaction manager and Spring 3.1.  So I converted to all transction management usign Spring 9even though it finally called Hibernate transatin management), and my transaction started appearing correctly.  So bascially, mising the transaction managers in JB7 caused me some headache.

          • 2. Re: Trouble migrating Envers 3.6 application from JBoss 4.x to 7.1
            dfisher95350

            Solved I think (a change to hibernate.transaction.factory_class). I will post an explanation for the record once I proof.

            • 3. Re: Trouble migrating Envers 3.6 application from JBoss 4.x to 7.1
              dfisher95350

              Shot ourselves in the proverbial foot. During the migration, we experimented with removing the Hibernate 3.6 JARs from our WAR, but it turned out our application was not ready to run properly with Hibernate 4.

               

              During those experiments, we twiddled with the configuration, and removed:

               

              hibernate.transaction.factory_class = org.hibernate.transaction.CMTTransactionFactory

               

              Which caused this setting to default to:

               

              org.hibernate.transaction.JDBCTransactionFactory

               

              ... which by its nature would produce much more limited transactional scopes: the entity update and the revision insert got separately scoped per fine-grained JDBC transaction.

               

              So, our hypothesis about 'different transactional behavior' was correct, but it was our own configuration change that caused it.