This can be replicated in Hibernate master. The guy had added some unit tests to the Infinispan testsuite that replicated the issue.
See https://github.com/galderz/hibernate-orm/tree/t_saugat And try running org.hibernate.test.cache.infinispan.functional.cluster.NonBasicIdInvalidationTestCase Fails with: org.hibernate.test.cache.infinispan.functional.NonBasicCitizen#org.hibernate.test.cache.infinispan.functional.CitizenPK@76 expected:<1> but was:<2> Cheers, On Jun 8, 2012, at 2:30 PM, Steve Ebersole wrote: > I agree. This sounds like the component being serialized as part of its > inclusion in the CacheKey rather than the component being "disassembled". > > On Fri 08 Jun 2012 08:18:52 AM CDT, Scott Marlow wrote: >> I'll be interested to hear which software versions are in use (I just >> asked in the below forum link). >> >> On 06/08/2012 08:01 AM, Galder Zamarreño wrote: >>> >>> On Jun 8, 2012, at 12:35 PM, Galder Zamarreño wrote: >>> >>>> >>>> On Jun 8, 2012, at 12:26 PM, Galder Zamarreño wrote: >>>> >>>>> Hi all, >>>>> >>>>> Re: https://community.jboss.org/message/739399#739399 >>>>> >>>>> This guy's using a combo of @EmbeddedId and @Embeddable in the tests his >>>>> provided, and this is resulting in cache key serialized payloads >>>>> differing for identical instances. Even in between runs, the last bit of >>>>> the payload varies. This obviously results in keys not being found in the >>>>> cache. >>> >>> The problem seems to come from here: >>> >>> CacheKey -> org.hibernate.type.TypeFactory$TypeScopeImpl -> >>> SessionFactoryImpl -> uuid >>> >>> So, each CacheKey is this case contains the UUID of the session factory, >>> and since each node's session factories are different, the UUIDs will be >>> too, which results in different payloads for the same key. >>> >>> This would appear to be a bug in the Hibernate side? 2LC providers do >>> nothing about CacheKey, they just know that an object needs to be >>> serialized. >>> >>> Btw, that a simple key like the one in the example provided generates 3KB >>> of byte[] sounds pretty excessive... >>> >>>>> >>>>> Apart from this issue which I'm currently investigating, I've spotted >>>>> that when the CacheKey is marshalled, it also marshalls the entity as >>>>> part of the key. That sounds rather inefficient, so is this guy: >>>> >>>> ^ I think this statement is wrong, bear with me while I confirm. >>> >>> ^ I was wrong with this. >>> >>>> >>>>> >>>>> a) using the right pattenr for @EmbeddedId + @Embeddable >>>>> b) is Hibernate behaving the right way here by having a reference to the >>>>> entity from cache key >>>>> >>>>> Cheers, >>>>> -- >>>>> Galder Zamarreño >>>>> Sr. Software Engineer >>>>> Infinispan, JBoss Cache >>>>> _______________________________________________ >>>>> hibernate-dev mailing list >>>>> hibernate-dev@lists.jboss.org >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>>> >>>> -- >>>> Galder Zamarreño >>>> Sr. Software Engineer >>>> Infinispan, JBoss Cache >>>> >>>> >>>> _______________________________________________ >>>> hibernate-dev mailing list >>>> hibernate-dev@lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >>> >>> -- >>> Galder Zamarreño >>> Sr. Software Engineer >>> Infinispan, JBoss Cache >>> >>> >>> _______________________________________________ >>> hibernate-dev mailing list >>> hibernate-dev@lists.jboss.org >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > -- > st...@hibernate.org > http://hibernate.org -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
