[infinispan-dev] Lazy deserialization and listeners (re: HHH-5552)

[Manik Surtani]

On 16 Sep 2010, at 08:31, Galder Zamarreño wrote:

> Hi,
> 
> Paul has opened an interesting JIRA in the Hibernate Infinispan 2LC code: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5552
> 
> The problem here is that Infinispan 2LC code maintains a series of listeners that can force deserialization of MarshalledValues within Transport thread which leads to CNFEs. MV deserialization here happens as a result of calling EventImpl.getKey()/EventImpl.getValue(). The key thing here is that one of the listeners actually uses these key/values to maintain a local cache for better performance. To solve this, Paul has come up with a solution which involves having a Cache wrapper and any listener added is wrapped around a listener that sets the correct CL.
> 
> I haven't seen similar problems so far, but considering that we might see more issues like this reported, I was wondering whether we could help solve this issue within Infinispan in a better way. I considered @Listener having an optional parameter which indicates whether getKey/getValue should return the MarshalledValues instead of their deserialized versions. This would solve half of the problem since local caches could stored MVs instead of deserialized versions. However, client listener could would then need to wrap keys into MarshalledValues which means that they'd have to pass an StreamingMarshaller but this is not exposed to clients. This avenue does not look very pretty since we're exposing internals, although it could be improved by providing some kind of MarshalledValue factory method that would not require clients to know anything about the Marshaller. 

Hmm, I don't think getKey()/getValue() should ever return a MarshalledValue as this is really pretty useless to callers.  If a caller calls either of these methods, they want the actual key or value and not some internal representation.

> I plan to go with Paul's workaround but I think we should keep this in mind and see if we can come up with a cleaner solution.

Yes, stick with this for now and if there is general need for such a feature we can think of something like perhaps adding a ClassLoader to the listener impl and having the notifier use this CL when deserializing stuff for a listener.  But too much for now - let's see if it is generally useful first.

Cheers
Manik

--
Manik Surtani
manik at jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org