[infinispan-dev] ConstantObjectTable

Galder Zamarreño galder at redhat.com
Wed Oct 13 02:58:10 EDT 2010


On Oct 11, 2010, at 12:58 PM, Mircea Markus wrote:

> 
> On 11 Oct 2010, at 11:54, Mircea Markus wrote:
> 
>> 
>> On 11 Oct 2010, at 11:46, Galder Zamarreño wrote:
>> 
>>> 
>>> On Oct 11, 2010, at 12:37 PM, Mircea Markus wrote:
>>> 
>>>> Hi,
>>>> 
>>>> I remember we had this discussion at one point, sorry if I am repeating it.
>>>> ConstantObjectTable has all the externalizer's statically defined within it. Can it just read them on the fly from the annotations existing on the object it needs to serialize? I.e. if e.g. TransientMortalCacheEntry is annotated as @Marshallable  why is it needed to add it to the ConstantObjectTable again?
>>> 
>>> There primary reason is: How is a node that hasn't serialized TransientMortalCacheEntry gonna know that what comes through the wire is a TransientMortalCacheEntry? It needs to know for a given ID, which externalizer to use to read. So, we either, did this statically or via annotation scanning of classpath. The latter is no no, so we went for static. Once we saw we needed static definition, we decided to do it both ways, for given a Class, give me the Externalizer (writing) and for a given ID, give me the Externalizer (reading)
>> Makes perfect sense - thanks! 
>> Is it possible for me to programatically update the ConstantObjectTable?
> Just to rock the boat :) It would be possible for the reader, if it doesn't find any mapping in the constant objects table to ask the sender which is the externalizer used. This would be an additional RPC/externalizer - no performance const really. It would complicate the code a bit though :)

Sure, rock the boat! That's what we're here for :)

You'd have to be careful about synchronizing as well, cos you could several requests in parallel arriving at the receiver and this having to send back one or several requests for which externalizer to use.

There's also the validation part to take into account. By having all Externalizers loaded at startup, we can quickly figure out whether any of the user externalizers clashes with existing externalizers, i.e. same ID is used. So, we'd catch this issues early whereas with your solution, this might unnoticed until the externalizer is used. 

Another thing to bear in mind is that we can't mandate Externalizers to be annotated cos it might not be under their control or they might not be able to modify them any more. So, by not being able to mandate this, how are we going to possibly figure out what the Marshaller to use at runtime?

Cheers,

>>> 
>>>> 
>>>> Cheers,
>>>> Mircea
>>>> 
>>>> 
>>>> _______________________________________________
>>>> infinispan-dev mailing list
>>>> infinispan-dev at lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>>> 
>>> --
>>> Galder Zamarreño
>>> Sr. Software Engineer
>>> Infinispan, JBoss Cache
>>> 
>>> 
>>> _______________________________________________
>>> infinispan-dev mailing list
>>> infinispan-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>> 
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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




More information about the infinispan-dev mailing list