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

[Steve Ebersole]

so JBC 3 needs this change anyway?  at which point it would be a total
drop-in replacement?

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
> >>
> > 
> 
>