Does envers only flush on transaction.commit()?

[gacsal]

Hello!

Sorry, but I did not found anything about following in the documents:
does envers only insert revision-data, when the transaction gets committed?

Why I ask:
In some cases I have to insert/update/delete a large number of entities,
therefore I need to call EntityManager.flush() and EntityManager.clear(),
otherwise I run into heap-problems.

I wrote a testcase, where I continuosly insert 100.000 entities, by flushing and clearing the entitymanager on every 5000 records.
When I do not activate the listeners of envers, I can insert all entities,
with low-heap-consumption, but when I activate envers's listeners,
I get OutOfMemory after ~ 30.000 entities.

So my questions are:
1.Is it a design decision to not to flush the revision entities multiple times in one transaction, to have one revision only per transaction?
2. Do you see some possibilities to support large transactions?

Thanks!

[adamw]

Hello,

yes, it's a design decision to only flush on commit. That's because an entity can change multiple times in a single transaction, and if you flushed earlier, then you'd have to undo the changes done so far etc (you only want max one rev entry per entity per transaction).

It would be possible to add flushing more often (for example on user demand), but that would require a code change. If you'd be willing to do a patch, please create a JIRA and attach it :)

Adam

[gacsal]

Hello Adam!

Thanks for the response.

Yes maybe I will prepare a patch, but let me ask something:
" then you'd have to undo the changes done so far etc (you only want max one rev entry per entity per transaction). "
What if we have multiple revisions per transaction?
I see no problems with that:
- yes, maybe we have more audit-data
- but the audit is still consistent (the revisionsNumber+entityId are still unique)

Thoughts?

Thanks & regards,

Karoly

[adamw]

Well, 1 transaction == 1 revision, so revNumber + entityId wouldn't be unique.

I think it's best to keep the one-rev-per-transaction. Otherwise you don't know which data comes together in a revision (it's important to group the data that are changed in one TX together).

The "undoing" part is written in fact, but not very well tested.

Adam