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

[Paul Ferraro]

----- Original Message -----
> From: "Galder Zamarreño" <galder at redhat.com>
> To: "Paul Ferraro" <paul.ferraro at redhat.com>
> Cc: "Jason T. Greene" <jason.greene 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>, "David M. Lloyd" <david.lloyd at redhat.com>
> Sent: Tuesday, March 6, 2012 2:02:44 PM
> Subject: Re: [jboss-as7-dev] AS7-4007 missing Infinispan dependency for clustered JPA second level cache
> 
> 
> On Mar 6, 2012, at 6:31 PM, 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.
> 
> Well, this is not exactly correct since 5.0. Internally, we
> differentiate between a global marshaller and a per-cache
> marshaller. What's the difference? The classloader with which
> they're configured.

Yes - but there's a difference between supplying a classloader per cache and providing a custom marshaller per cache.

> Since 5.0, you can configure the classloader to use per cache. You
> can even configure the classloader per invocation with
> cache.with(cl)….

And we use both of these.  The ClassLoader supplied to the CacheConfiguration is used to resolve configuration classes (e.g. cache stores).  The AS7 2LC region factory implementations (which extend hibernate-infinispan) currently use the ClassLoader per invocation to resolve entity/PK objects - but this is too restrictive, since the Infinispan's marshaller needs to know about more classes than are available to the application class loader (hence this discussion), and even that is still not without issues (e.g. ISPN-1220).

> If that's not helping you, we were wasting our time when we did
> this...

I disagree.  Allowing a user to supply a classloader to a cache/invocation is incredibly useful.

> > 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
> 
> Isn't a class resolver and a class loader, functionality wise, doing
> the same thing? I wonder if a custom classloader could not be built
> that delegates to a ModularClassResolver...

Functionally, yes, but technically, no.  The ModularClassResolver resolves classes using the class name and the name of its module, whereas a ClassLoader resolves classes using just the class name.

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

Apart from possibly adding MarshallingConfiguraion hooks to infinispan-core, what other solution do you have in mind?

Paul