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

[Paul Ferraro]

----- 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.