[infinispan-dev] [ISPN-125] Reading part of dynamic externalizer mappings

[Galder Zamarreno]

On 07/16/2009 06:10 PM, Galder Zamarreno wrote:
> Hi,
>
> Re: https://jira.jboss.org/jira/browse/ISPN-125
>
> I've been thinking more about this and I don't have the reading part
> very clear. At runtime, it's very easy to check the externalizer map to
> see if there's externalizer for class A and if there isn't any, inspect
> the class for @Marshallable annotation, instantiate the A's Externalizer
> class and add it to the map.
>
> However, the reading part is a fairly difficult problem to crack cos all
> you'd get would be an Id which you'd need to map back to an Externalizer
> that will be used for reading. However, how does the reader know what's
> the mapping Id to Externalizer mapping?
>
> One option, rather brutal, would be to look up the entire classpath for
> a class containing a @Marshallable with the index you're after.

Although brutal, this might the way forward. I mean, even if it's a 
lengthy process, the first time you do it, for every class with 
@Marshallable annotation that you find, you could add it to the map, 
regardless of whether it matches the one you're after. So, next time 
around, you'd have already done the hard work and would only do scanning 
if the mapping was not there.

Vladimir, can you help with something like this?

>
> Another option would be that the 1st time someone writes an instance of
> that class A, it adds a String form of the fully qualified class name to
> the wire. So, the reader can check the externalizer map and if the id
> not present, read the class name and resolve it and add the mapping.
> However, this breaks the moment you have two different nodes sending a
> class for the 1st time. They would both add the class name but only the
> 1st one to arrive would resolve the class name correctly, the 2nd time
> it arrives on the node, cos the mapping would already be there, it would
> read the object directly, failing cos there's also the class name on the
> wire.

This option is definitely broken and I don't like it at all.

>
> Anyone has any other ideas?
>
> It's worth bearing in mind that adding this dynamic behaviour adds
> complexity the code and it forces previously non-concurrent collections
> to be concurrent, hence performance will degrade compared to the current
> solution. It's worth keeping in mind that users will always be able to
> implement their j.i.Externalizable, which will be less performant than
> our internal solution but might be reasonable enough.
>
> One thing is for sure here, the indexes need to be tied down and I'm
> already working on it.

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache