Re: [jbosscache-dev] Fwd: hibernate-dev Digest, Vol 9, Issue 88
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>
>> Subject: [hibernate-dev] org.hibernate.cache redesign
>> To: hibernate-dev <hibernate-dev(a)lists.jboss.org>
>> Message-ID: <460ACB0A.4010205(a)hibernate.org>
>> 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.
>>