I had hoped we could easily solve this by overriding the default setting for org.hibernate.envers.do_not_audit_optimistic_locking_field to false and Envers would see that the parent entity was modified (via the version attribute) and audit the row; however that isn't the case since ORM handles the OPTIMISTIC_FORCE_INCREMENT as a before transaction completion task.

I need to investigate if we could look into plugging into the LockEventListener and based on the proposed LockEvent state, make a decision about whether or not we need to perform any activity on an entity. The tricky part is obtaining the necessary entity state to generate the audit row.

The following is mainly for my benefit, but the LockEventListener basically registers a BeforeTransactionCompletion callback which is where the actual version will be incremented at the end of the transaction. We need to determine if there is any scenario where the Envers BeforeTransactionCompletion callback fires before this ORM one. If it does, we will need to get creative on how we can determine the old/new version values for the audit row. If it does not, it could be as simple as cache the current version during the LockEventListener and then get the new version when processing the AuditProcess entries and generate an audit row.

I believe the caveat here would be to only do this under a specific use case:

1. Optimistic locking field is audited, e.g. org.hibernate.envers.do_not_audit_optimistic_locking_field=false.
2. The only change to the entity was the optimistic locking field, no actual entity attributes were modified. If attributes were modified, the normal PostUpdateEvent callbacks would handle this use case and therefore audit the row without any special logic.

Thoughts?