-->
These old forums are deprecated now and set to read-only. We are waiting for you on our new forums!
More modern, Discourse-based and with GitHub/Google/Twitter authentication built-in.

All times are UTC - 5 hours [ DST ]



Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 
Author Message
 Post subject: ThreadLocal Interceptors and onFlushDirty
PostPosted: Mon Aug 07, 2006 5:10 am 
Newbie

Joined: Mon Aug 07, 2006 4:54 am
Posts: 2
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?


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 07, 2006 11:02 am 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
Quote:
declaring the Interceptor as a ThreadLocal.


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


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 07, 2006 11:53 am 
Newbie

Joined: Mon Aug 07, 2006 4:54 am
Posts: 2
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!


Top
 Profile  
 
 Post subject:
PostPosted: Mon Aug 07, 2006 2:50 pm 
Hibernate Team
Hibernate Team

Joined: Mon Aug 25, 2003 9:11 pm
Posts: 4592
Location: Switzerland
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.


Top
 Profile  
 
 Post subject: Re: ThreadLocal Interceptors and onFlushDirty
PostPosted: Wed Jul 15, 2009 4:26 am 
Newbie

Joined: Wed Mar 03, 2004 8:52 am
Posts: 5
Location: Brussels, Belgium
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Forum locked This topic is locked, you cannot edit posts or make further replies.  [ 5 posts ] 

All times are UTC - 5 hours [ DST ]


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
© Copyright 2014, Red Hat Inc. All rights reserved. JBoss and Hibernate are registered trademarks and servicemarks of Red Hat, Inc.