1. Yes, that's what the RevisionEntity is for. Generally, I think you'll want to store the user per revision (transaction), not per entity, as typically in one transaction 1 user modifies the entities. So, storing it together with the entity would be duplicating information. Getting that information from a Seam context is very easy, you just need to implement a RevisionListener which looks the appropriate component.
2. No, the audit entries are written synchronously at the end of the transaction. This guarantees proper ordering (so that newer transactions aren't stored before older ones) and data integrity (that the audit tables always contain proper data). There is some time lag incured by auditing, but it's not very big.
Thanks for the quick responce, I somehow did not get the initimation that it is responded.
One more questions, are there any performance improvement that is done by Envers over and above the normal DB update, like batching of the inserts and updates and things like that?
Also let us know if we can asynchronously post the audit information it to another DB (audit DB), than the destination DB on which the online application is working on. Just to ease-up the load on the destination DB.
Envers itself doesn't do any batch optimizations - but as it uses Hibernate, all performance settings done there apply also. So if you specify a batch size in hibernate configuration, this will be used by Envers also.
As to asynchronously posting the audit information, this is of course possible (eg via JMS or sth like that), but would require code changes (basically when a WorkUnit is executed, instead of calling session.save, you'd have to send the message).
Maybe you'd be interested in providing a patch which adds such support? :)