Btw, re. Hibernate calling remove() in an afterCompletion() block, this will be properly fixed in Hibernate 3.3.x series and a workaround is now in place for the upcoming Hibernate 3.2.3. Kevin, thanks for your input on this. From Steve: On 29 Mar 2007, at 16:23, Manik Surtani wrote: > Based on a conversation with Steve about > > [1] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=103983 > [2] http://forum.hibernate.org/viewtopic.php?t=972301 > [3] http://www.jboss.com/index.html?module=bb&op=viewtopic&t=102202 > > and a recent support case, this all has to do with a shortcoming of > how Hibernate (3.2.x) treats batch operations. For most > operations, it uses ConcurrencyStrategies to determine how cache > interactions work and this is different for transactional (JBoss > Cache) vs. other strategies. For batch operations, however, the > codepath in [1] above is used for *all* cache strategies and this > causes problems since calling cache.remove() in an afterCompletion > () block of a Synchronization is in fact illegal as the transaction > in question is no longer valid nor is it guaranteed to be removed. > > Fixing this is a part of Steve's org.hibernate.cache redesign > outlined below, but this is targeted for Hibernate 3.3 only. > > See http://opensource.atlassian.com/projects/hibernate/browse/HHH-2532 > > > > > > On 29 Mar 2007, at 16:08, Manik Surtani wrote: > >> From the Hibernate dev list, from yesterday, detailing out Steve's >> plans for refactoring in HIbernate, wrt. 2nd level caches: >> >> >> Begin forwarded message: >> >>> From: hibernate-dev-request(a)lists.jboss.org >>> Date: 28 March 2007 21:08:02 BDT >>> To: hibernate-dev(a)lists.jboss.org >>> Subject: hibernate-dev Digest, Vol 9, Issue 88 >>> Reply-To: hibernate-dev(a)lists.jboss.org >>> >>> <SNIP /> >>> >>> Message: 2 >>> Date: Wed, 28 Mar 2007 15:07:38 -0500 >>> From: Steve Ebersole <steve(a)hibernate.org&gt; >>> Subject: [hibernate-dev] org.hibernate.cache redesign >>> To: hibernate-dev <hibernate-dev(a)lists.jboss.org&gt; >>> Message-ID: <460ACB0A.4010205(a)hibernate.org&gt; >>> Content-Type: text/plain; charset="iso-8859-1" >>> >>> So I am in the midst of redesigning the stuff in the >>> org.hibernate.cache package >>> as we discussed previously during our last roadmap discussion. >>> This is work I >>> will commit to trunk, but not to Branch_3_2 and which will start >>> the 3.3 >>> development line since it will require significant SPI changes. >>> >>> So I just wanted to start a more detailed discussion regarding my >>> plans here and >>> to see if anyone wants to add anything and to make sure I am not >>> missing anything. >>> >>> So the first aspect is to split and rename the concept which is >>> currently termed >>> org.hibernate.cache.Cache. Now, there will be a base interface >>> named >>> o.h.c.Region, with 4 specializations: EntityRegion, >>> CollectionRegion, >>> QueryResultsRegion, TimestampsRegion (whose purpose are hopefully >>> self-evident :) >>> >>> Next, we need a SPI for building these various types of regions. >>> This is the >>> role of the new o.h.c.SecondLevelCache interface. It is somewhat >>> akin to >>> o.h.c.CacheProvider in terms of contract except that I break out >>> different >>> methods for building each "region type". Currently there is one >>> implementation >>> OOTB: o.h.c.impl.SecondLevelBridge which acts as a bridge between >>> this new API >>> and the older CacheProvider stuff, which I decided to leave in >>> place for the >>> time being to make migration easier initially. But this is >>> where, for example, >>> we'd plug in more intelligent region management like we have been >>> discussing >>> with the JBossCache team. >>> >>> These changes also affect how o.h.c.CacheConcurrencyStrategy >>> works. First, I >>> took this refactoring as an opportunity to rename >>> CacheConcurrencyStrategy to >>> AccessStrategy since that is more true to the role. And actually >>> this is split >>> as well into EntityRegionAccessStrategy and >>> CollectionRegionAccessStrategy, >>> because I found this more natural and easier to follow from an >>> implementation >>> perspective (I did not really see a philosophical reason for this >>> split). >>> >>> Anyway, I attached the initial version of these contracts for an >>> early peek. >>>