We are implementing audit logging in our application, based on the code from the end of chapter 8. This approach suggests integrating an Interceptor with the ThreadLocals used in a HibernateUtil class. We have tried out this suggestion, declaring the Interceptor as a ThreadLocal. The session and transaction are also ThreadLocals, as described in the book.

The problem we have with this is that when the container the code runs in assigns a new thread, we have a new Session and a new Interceptor. This means that Interceptor events will be called for each ThreadLocal Interceptor that is running. When an update takes place, we're noticing that onFlushDirty happens multiple times, resulting in multiple log entries that are identical.

The duplicate entries in the updates list don't match each other via List.contains(), so a custom contains method on the list of state changes would have to be written.

Is there a cleaner approach? Is it true that the ThreadLocals are causing this problem? Has anyone else followed the approach described in the book and not seen these symptoms?

Nowhere does the book claim that you should put/declare/whatever the Interceptor as/in a ThreadLocal variable.

You're right, it doesn't claim that you should as necessity, but it does suggest this pattern. Pg 345 of the second, corrected edition, under "Enabling the interceptor".

Further inspection today has led me to realise that it's not the threading that's the problem here. The actual issue is that querying the database after making changes to objects but before making them persistent was causing dirty flushes to occur.

ThreadLocal sessions and interceptors aren't causing duplicate entries at all. Differences between the cache and the database aer invoking the dirty flush. Apologies for the original post. Thanks for taking a look anyway, Christian!

Actually, it is true that there were versions of HibernateUtil in some CaveatEmptor downloads that had a "thread-bound interceptor". I wouldn't recommend that today (no particular reason, I just try to avoid managing ThreadLocals on my own unless absolutely necessary) and I didn't think it was in the book at all. It's all hypothetical with Hibernate3 anyway, as there are much better solutions with CurrentSessionContext.

Hi,
Sorry to dig out this old post but we are also trying to implement an audit log interceptor, starting from the book solution.

The problem is the book then only recommend that "any interceptor that is set on a Configuration and active for all Sessions must be implemented thread-safe!"

As we searched for a solution, we only could think of a ThreadLocal solution (making the 'inserts', 'updates' members ThreadLocal). We use Spring to create our SessionFactory, we cannot assign manually a Session with a new interceptor instance to each new thread (in an Eclispe RCP environment).

We just want to ensure concurrent accesses to the interceptor won't mess with each other Sets ... Is there another, cleaner solution in your opinion ?

Thanks a lot,
Paulo.