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

[Brian Stansberry]

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