[hibernate-dev] Caching @EmbeddedId/@Embeddable instances

[Galder Zamarreño]

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

--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache