Question

I have been debugging some strange envers behaviour in my code for a couple of days and have stumbled on something that surprised me. I have confirmed that this is not contributing to my problem but I thought that it would be worth checking my assumptions anyway.

If I get the current Hibernate session in multiple places in a single thread (I am using thread session context) I will always get the same session and therefore I will hit the same level one cache.

I had assumed similar behaviour with envers when getting an audit reader instance. I am using AuditReader reader = AuditReaderFactory.get(session); to get AuditReader instances. I noticed that every time this is called (even within the same session context) I get a new audit reader instance, containing a unique first level cache instance.

It looks like this would result, at best, in the performance hit of multiple, possibly overlapping caches.

I had assumed that, for a session context, I would always get the same AuditReader instance and therefore, a single first level cache. I cannot think of a reason why this would not be the case.

This leaves me with four possibilities:

  1. I am not using the correct method to get a session context's audit reader
  2. There is a good reason for having multiple audit reader instances
  3. There is a bug somewhere in the depths of envers
  4. It does not make sense to reuse audit reader instances.

Can someone please provide some insight on this.

Thanks.

Was it helpful?

Solution

If you look at the implementation of AuditReaderFactory (here), a new instance of an AuditReaderImpl is created on each call; the instances are not cached anywhere themselves.

It isn't also specified anywhere that you should get the same instance given the same session; so your request can be treated as a "feature request", but I wouldn't say it's a bug.

There's no specific reason not to reuse same audit reader instances.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top