[jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache

[Jason T. Greene]

On 3/6/12 11:31 AM, Paul Ferraro wrote:
> ----- Original Message -----
>> From: "Jason T. Greene"<jason.greene at redhat.com>
>> To: "David M. Lloyd"<david.lloyd at redhat.com>
>> Cc: "Galder Zamarreño"<galder at redhat.com>, "Paul Ferraro"<pferraro at redhat.com>, "Bela Ban"<bban at redhat.com>,
>> "infinispan -Dev List"<infinispan-dev at lists.jboss.org>, hibernate-dev at lists.jboss.org,
>> "jboss-as7-dev at lists.jboss.org Development"<jboss-as7-dev at lists.jboss.org>
>> Sent: Tuesday, March 6, 2012 10:30:11 AM
>> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
>>
>> On 3/6/12 9:28 AM, David M. Lloyd wrote:
>>> On 03/06/2012 09:21 AM, Galder Zamarreño wrote:
>>>> This reminds me that we had a discussion about this a few months
>>>> back: http://goo.gl/DJLhB
>>>>
>>>> At the time, it wasn't clear whether you can use
>>>> ModularClassResolver in a non-module env. Seems like it's not
>>>> possible.
>>>>
>>>> So, one option is to have a class resolver lookup class, or
>>>> similar so that AS7 can pass us the right ClassResolver.
>>>>
>>>> There might a quicker option here though:
>>>> - Extend VersionAwareMarshaller (http://goo.gl/bu8CF) and provide
>>>> a variant of JBossMarshaller (http://goo.gl/o9Ro3) in Infinispan
>>>> (this requires JBossMarshaller to be made non-final)
>>>> - Override JBossMarshaller.inject(), call super.inject() and then
>>>> call baseCfg.setClassResolver(…)
>>>> - This would require that the VersionAwareMarshaller extension be
>>>> passed the ModuleLoader that ModularClassResolver requires.
>>>> - Configure Infinispan with this new marshaller, via
>>>> SerializationConfiguration. Thankfully you can now pass an
>>>> instance of the marshaller to it, so no need to do any magic
>>>> ModuleLoader lookup from the VersionAwareMarshaller extension.
>>>>
>>>> Scott, other than the change in JBossMarshaller to be made
>>>> non-final, the rest can built on AS7. Wanna have a go? Ping me on
>>>> IRC if you need help.
>>>>
>>>> Cheers,
>>>>
>>>> p.s. Silly question, how come this issue is not present in HTTP
>>>> session replication use case or EJB3 SFSB?
>>>
>>> It actually is present anywhere we're using Infinispan (I think).
>>>   It
>>> just hasn't blown up yet anywhere public (in this case it's a 90%
>>> effective solution versus a 100% effective solution).
>>
>> Session replication does setup a custom marshaller, so it does in
>> fact
>> work. I think the issue is just that the hibernate-infinispan, which
>> is
>> part of the hibernate project set, and not AS code does not do this,
>> and
>> it doesn't expose a way to do it.
>
> Sort of...
>
> To summarize:
> The fundamental issue is that Infinispan uses the same marshaller instance for all caches within a cache manager - which doesn't map cleanly to our use case, which uses a cache instance per application - thus requires cache-grained marshalling configuration.
>
> To work around this, we typically store MarshalledValues in the cache - which are marshalled/unmarshalled using a marshalling configuration specific to the application (e.g. via a ModularClassResolver using the ModuleLoader of the deployment unit).
> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/MarshalledValue.java
> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/SimpleMarshalledValue.java
> https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/java/org/jboss/as/clustering/HashableMarshalledValue.java
>
> So, essentially Infinispan itself only ever has to marshal/unmarshal a byte[] wrapper - so the AS has full control over the marshalling process.
>
> I would recommend that the 2LC do something similar, and include a mechanism for providing a MarshallingConfiguration per persistence unit.
Well the lazy deserialization thing was really to solve the legacy 
problem of receiving deployment data without knowing the classloader for 
the deployment. In 7 we know this know, although we still have the 
problem that the value is only usable if the deployment is up and running.

Although, I don't see how we need per application marshalling 
configuration. The ModularClassResolver will work globally as deployment 
module identity is globally unique.

-- 
Jason T. Greene
JBoss AS Lead / EAP Platform Architect
JBoss, a division of Red Hat