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?
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
