Hi. I am using Hibernate Envers 1.2.1, and recently encountered some bizarre behavior. It looks like a newly created collection is deleted after Envers does its thing on transaction commit. If I unwire AuditEventListener from the session factory, the collection is preserved. The entity whose collection is being deleted is not even being audited: the relationship is more like AuditedEntity -> PlainEntity -> collection. Here's the sequence of events I see:

1. Create AuditedEntity, establish many-to-one relationship with PlainEntity.
2. Add some elements to PlainEntity.someCollection.
3. Commit. I put a breakpoint in Hibernate's ActionQueue, and notice nothing unusual queued on flush.
4. After AuditEventListener does its work, ActionQueue now has instructions to blow away PlainEntity.someCollection.

Any suggestions on how I might diagnose this problem? Thanks.

I think I see what's going on. The collection in question is a @CollectionOfElements, so its lifecycle is entirely managed by the containing entity. I updated the collection by calling PlainEntity.setSomeCollection(new set). This orphaned the old collection. When Envers is wired in, it seems to disturb things around that the flushes execute the operations in the wrong order:

1. First, the new collection elements are inserted.

2. Later, somewhere during AuditSync.beforeCompletion, Hibernate realizes that the old collection was removed and notes this in the session's ActionQueue. It eventually issues a delete from ... statement. This leaves me with an empty collection.

I changed the collection operation to do:

plainEntity.getSomeCollection().clear();
plainEntity.getSomeCollection().addAll(new set);

That seems to work around the problem. Unfortunately, I don't really have the time to poke into this further to file a proper bug report. I thought I'd just write this followup to my original post in case it helps.