9:58 a.m.
Carlo,
FYI, there are a bunch of EJB3 clustered entity test failures in AS
trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss
Cache 2.0.0. Basically, this is a temporary mismatch between Hibernate
and JBC. There's work in Hibernate Core's trunk for the 3.3 release that
can let us resolve this, but for now the tests are going to fail.
Problem is the integration layer ends up calling the JBC
putForExternalRead() method when it needs to cache something in the
"UpdateTimestampsCache". JBC treats a calls to this method as a no-op
if the cache node in question already exists. This is new behavior in
JBC 2.0. It's the necessary and intended behavior when the method is
called for caching entities and collections. But when it's called for
the UpdateTimestampsCache, it causes problems. The Hibernate 3.3.
codebase gives us the flexibility to call a different method for the
UpdateTimestampsCache call; to fix the problem we need determine the
exact behavior we want for the UpdateTimestampsCache call and make the
appropriate call to JBC.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5:45 a.m.
On Jul 2, 2007, at 4:58 PM, Brian Stansberry wrote:
FYI, there are a bunch of EJB3 clustered entity test failures in AS
trunk due to a bad interaction between Hibernate 3.2.4.SP1 and
JBoss Cache 2.0.0. Basically, this is a temporary mismatch between
Hibernate and JBC. There's work in Hibernate Core's trunk for the
3.3 release that can let us resolve this, but for now the tests are
going to fail.
Problem is the integration layer ends up calling the JBC
putForExternalRead() method when it needs to cache something in the
"UpdateTimestampsCache". JBC treats a calls to this method as a no-
op if the cache node in question already exists. This is new
behavior in JBC 2.0. It's the necessary and intended behavior when
the method is called for caching entities and collections. But
when it's called for the UpdateTimestampsCache, it causes problems.
The Hibernate 3.3. codebase gives us the flexibility to call a
different method for the UpdateTimestampsCache call; to fix the
problem we need determine the exact behavior we want for the
UpdateTimestampsCache call and make the appropriate call to JBC.
Can we put this on the JBoss Cache/Hibernate wiki page with a final
conclusion and guidelines for current users of both?
4:57 p.m.
Christian Bauer wrote:
On Jul 2, 2007, at 4:58 PM, Brian Stansberry wrote:
> FYI, there are a bunch of EJB3 clustered entity test failures in AS
> trunk due to a bad interaction between Hibernate 3.2.4.SP1 and JBoss
> Cache 2.0.0. Basically, this is a temporary mismatch between
> Hibernate and JBC. There's work in Hibernate Core's trunk for the 3.3
> release that can let us resolve this, but for now the tests are going
> to fail.
>
> Problem is the integration layer ends up calling the JBC
> putForExternalRead() method when it needs to cache something in the
> "UpdateTimestampsCache". JBC treats a calls to this method as a no-op
> if the cache node in question already exists. This is new behavior in
> JBC 2.0. It's the necessary and intended behavior when the method is
> called for caching entities and collections. But when it's called for
> the UpdateTimestampsCache, it causes problems. The Hibernate 3.3.
> codebase gives us the flexibility to call a different method for the
> UpdateTimestampsCache call; to fix the problem we need determine the
> exact behavior we want for the UpdateTimestampsCache call and make the
> appropriate call to JBC.
Can we put this on the JBoss Cache/Hibernate wiki page with a final
conclusion and guidelines for current users of both?
I added a version of the above to
http://wiki.jboss.org/wiki/Wiki.jsp?page=JBossCacheHibernateAlignment.
As mentioned there, a bunch of us will be meeting the week of July 23 to
deal with these issues. We'll update the wiki after those discussions.
As for "current users of both", the only code I'm aware of that
currently tries to integrate Hibernate and JBC 2.0 is the EJB3 stuff in
AS trunk. Unless I hear about an impending release off that code base, I
intend to leave that as is until we sort it out at the end of the month.
There is a "cache-jbosscache2" directory structure in Hibernate Core
trunk, but at the moment that's empty.
--
Brian Stansberry
Lead, AS Clustering
JBoss, a division of Red Hat
brian.stansberry(a)redhat.com
5:20 p.m.
On Jul 3, 2007, at 11:57 PM, Brian Stansberry wrote:
I added a version of the above to http://wiki.jboss.org/wiki/
Wiki.jsp?page=JBossCacheHibernateAlignment. As mentioned there, a
bunch of us will be meeting the week of July 23 to deal with these
issues. We'll update the wiki after those discussions.
Thanks, that helps out many people who want to know what the current
status is.
6457
days inactive
6458
days old
3 comments
2 participants
participants (2)
-
Brian Stansberry -
Christian Bauer