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
[EMAIL PROTECTED]
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
Principal Software Engineer
JBoss, a division of Red Hat
http://jboss.com
http://redhat.com
[EMAIL PROTECTED]
[EMAIL PROTECTED]
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
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
[EMAIL PROTECTED]
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
