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

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

    Douglas Fisher Newbie

      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.