remove() in afterCompletion() WAS: [jbosscache-dev] Fwd: hibernate-dev Digest, Vol 9, Issue 88
Manik Surtani
manik at jboss.org
Fri Mar 30 03:46:50 EDT 2007
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:
> Manik, you said you thought this was not a problem for
> pessimistically locked TreeCaches, but I went ahead and added a
> protection against both:
>
> public void afterTransactionCompletion(boolean success) throws
> HibernateException {
> ///////////////////////////////////////////////////////////////
> ////////
> // HACK ALERT!!!!!
> if ( session.getFactory().getSettings().getCacheProvider()
> instanceof org.hibernate.cache.OptimisticTreeCacheProvider
> || session.getFactory().getSettings
> ().getCacheProvider() instanceof
> org.hibernate.cache.TreeCacheProvider ) {
> return;
> }
> ///////////////////////////////////////////////////////////////
> ////////
> evictEntityRegions();
> evictCollectionRegions();
> }
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 at lists.jboss.org
>>> Date: 28 March 2007 21:08:02 BDT
>>> To: hibernate-dev at lists.jboss.org
>>> Subject: hibernate-dev Digest, Vol 9, Issue 88
>>> Reply-To: hibernate-dev at lists.jboss.org
>>>
>>> <SNIP />
>>>
>>> Message: 2
>>> Date: Wed, 28 Mar 2007 15:07:38 -0500
>>> From: Steve Ebersole <steve at hibernate.org>
>>> Subject: [hibernate-dev] org.hibernate.cache redesign
>>> To: hibernate-dev <hibernate-dev at lists.jboss.org>
>>> Message-ID: <460ACB0A.4010205 at 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.
>>> -------------- next part --------------
>>> A non-text attachment was scrubbed...
>>> Name: cache-redesign.zip
>>> Type: application/x-zip-compressed
>>> Size: 12848 bytes
>>> Desc: not available
>>> Url : http://lists.jboss.org/pipermail/hibernate-dev/attachments/
>>> 20070328/f48e8d36/cache-redesign.bin
>>>
>>> ------------------------------
>>>
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>>
>>> End of hibernate-dev Digest, Vol 9, Issue 88
>>> ********************************************
>>
>> --
>> Manik Surtani
>>
>> Lead, JBoss Cache
>> JBoss, a division of Red Hat
>>
>> Email: manik at jboss.org
>> Telephone: +44 7786 702 706
>> MSN: manik at surtani.org
>> Yahoo/AIM/Skype: maniksurtani
>>
>>
>> _______________________________________________
>> jbosscache-dev mailing list
>> jbosscache-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
>
> --
> Manik Surtani
>
> Lead, JBoss Cache
> JBoss, a division of Red Hat
>
> Email: manik at jboss.org
> Telephone: +44 7786 702 706
> MSN: manik at surtani.org
> Yahoo/AIM/Skype: maniksurtani
>
>
> _______________________________________________
> jbosscache-dev mailing list
> jbosscache-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/jbosscache-dev
--
Manik Surtani
Lead, JBoss Cache
JBoss, a division of Red Hat
Email: manik at jboss.org
Telephone: +44 7786 702 706
MSN: manik at surtani.org
Yahoo/AIM/Skype: maniksurtani
More information about the jbosscache-dev
mailing list