there's a performance hit only when saving changes in audited entities/properties. If you are changing non-audited entities, there's almost no additional operations (only a couple of if-s in java).
That's true that the revisions are global, but that's needed for the relation auditing to work correctly.
More precisely, for each transaction there's:
* one insert for each changed entity into the corresponding _aud table
* one insert into the rev_info table
Thanks for the reply. I understand that on non-audited entities there is little impact, but I was wondering (or hoping!) if someone had measured the impact on the audited entities.
Our environment involves multiple JBoss instances in a cluster, with hundreds of transactions per second (we hope). With the model used in Envers, how are you setting the revision number?
Presumably with a sequence or some form of max value on the REVINFO table? How well does this scale across a number of boxes, that might all be making changes? I'm concerned that this access to the REVINFO table and setting the revision number is a bottleneck.
Obviously I could (and probably should) test this myself but I don't have a lot of time to think about this right now. If I get around to it I'll post some results here.
The way the revision id is generated is up to you. Normally it's a sequence (e.g. in Postgres) or an auto_increment field (e.g. in MySQL). But you can configure the id generator yourself, by creating a custom revision entity.
As to performance measurments, even if there were some, I doubt they would have much value to you, as I think this is very application-specific, so I guess you'll be best off by doing some the way you are going to use Envers .