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

----- Original Message ----- > From: "Jason T. Greene"<jason.greene(a)redhat.com> > To: "David M. Lloyd"<david.lloyd(a)redhat.com> > Cc: "Galder Zamarreño"<galder(a)redhat.com>, "Paul Ferraro"<pferraro(a)redhat.com>, "Bela Ban"<bban(a)redhat.com>, > "infinispan -Dev List"<infinispan-dev(a)lists.jboss.org>, hibernate-dev(a)lists.jboss.org, > "jboss-as7-dev(a)lists.jboss.org Development"<jboss-as7-dev(a)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/j... https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j... https://github.com/jbossas/jboss-as/blob/master/clustering/api/src/main/j... 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.