[hibernate-dev] cache-jbosscache3 module for Hibernate Core

[Brian Stansberry]

Steve Ebersole wrote:
> so JBC 3 needs this change anyway?  

Yes, if it wants to go in, say, JBoss AS 5.2.  Which I'm quite sure the 
JBC team wants, since they made a bunch of other more significant 
changes to ensure compatibility. This one's real trivial.

> at which point it would be a total
> drop-in replacement?
> 

Yes. I just did a diff between head of trunk (which passes 100% w/ JBC 
3.0.0.CR1 plugged in) and the hibernate-3.3.1.GA tag and the only 
differences are two places where the missing 
DefaultCacheFactory.getInstance() call was replaced.

If JBC 3 were used as the default in Hibernate 3.4, it should be 
possible for users to downgrade to JBC 2 as well. They would have to 
provide their own cache config that doesn't specify MVCC locking, but it 
should be possible to ensure the hibernate/jbc integration layer doesn't 
use any JBC 3-specific API. This would require testing of course, most 
likely via a separate maven profile, which would be something of a pain 
in the ass.

> Just want to make sure i fully understand.
> -  
> 
> Steve Ebersole
> Project Lead
> http://hibernate.org
> steve at hibernate.org
> 
> Principal Software Engineer
> JBoss, a division of Red Hat
> http://jboss.com
> http://redhat.com
> steve.ebersole at jboss.com
> steve.ebersole at redhat.com
> 
> 
> On Fri, 2008-10-17 at 16:48 -0500, Brian Stansberry wrote:
>> Just ran the current trunk testsuite for cache-jbosscache2 using JBC 
>> 3.0.0.CR1 and there are no problems.
>>
>> However, there are a 21 failures trying to use 3.0.0.CR1 in Hibernate 
>> 3.3.1. All seem to be due to the removal of the 
>> DefaultCacheFactory.getInstance() method.  The failing calls are not in 
>> the testsuite; they are in the main code. So, JBC 3 as is will not work 
>> in Hibernate 3.3.
>>
>> To have JBC 3 be considered API compatible for inclusion in AS 5.x, this 
>> method would need to be restored.
>>
>> Steve Ebersole wrote:
>>> I think we should officially move to "inclusion" of JBossCache 3.0 in
>>> 3.4 which is not too far off.  For 3.3 it is easy enough for users to
>>> override Hibernate's declaration of JBossCache version to use 3.0 via
>>> Maven  *provided* the API really is compatible (drop-in replacement
>>> wise)
>>>
>>> -  
>>>
>>> Steve Ebersole
>>> Project Lead
>>> http://hibernate.org
>>> steve at hibernate.org
>>>
>>> Principal Software Engineer
>>> JBoss, a division of Red Hat
>>> http://jboss.com
>>> http://redhat.com
>>> steve.ebersole at jboss.com
>>> steve.ebersole at redhat.com
>>>
>>>
>>> On Mon, 2008-10-13 at 09:18 -0500, Brian Stansberry wrote:
>>>> Manik Surtani wrote:
>>>>> Guys,
>>>>>
>>>>> The API of JBC 3.0 is compatible with 2.x so the actual provider code 
>>>>> should not change, but we probably want to test MVCC as a locking scheme 
>>>>> as well.
>>>>>
>>>>> So, we either
>>>>>
>>>>> 1)  need a cache-jbosscache3 module (yuk!), copy the providers and 
>>>>> existing tests from cache-jbosscache2 and add a few extra tests.
>>>>>
>>>>> or,
>>>>>
>>>>> 2)  assume that cache-jbosscache2 refers to an API and not a version of 
>>>>> the cache.  So update the cache used in cache-jbosscache2 to 3.0.0, and 
>>>>> add the extra MVCC tests as well.
>>>>>
>>>>> My pref would be for 2, what do you guys think?
>>>>>
>>>> Had a *quick* look at the code, and looks like the only direct use of 
>>>> the JBC node locking scheme is a check for OPTIMISTIC in the JBC config, 
>>>> which if true leads to use of classes that store versions in the cache. 
>>>> With MVCC we don't need to store versions, so looks like the existing 
>>>> logic is fine.
>>>>
>>>> If the hibernate guys object to changing the dependency to 3.x, we could 
>>>> look at handling this via a maven profile. If there's no compile time 
>>>> dependency on JBC 3 in the main code or the tests (likely, since MVCC is 
>>>> configured via XML) then we could isolate execution of the MVCC tests in 
>>>> a profile.
>>>>
>>>> Downside to the profile approach is the standard JBC configs that ship 
>>>> would still use PESSIMISTIC/OPTIMISTIC.
>>>>
>>>>> Cheers
>>>>> -- 
>>>>> Manik Surtani
>>>>> Lead, JBoss Cache
>>>>> manik at jboss.org
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> hibernate-dev mailing list
>>>>> hibernate-dev at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> 


-- 
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry at redhat.com