[infinispan-dev] Providing a context for object de-serialization

Galder Zamarreño galder at redhat.com
Fri Jul 6 10:06:29 EDT 2012


On Jun 26, 2012, at 6:13 PM, Sanne Grinovero wrote:

> Imagine I have a value object which needs to be stored in Infinispan:
> 
> class Person {
>   final String nationality = ...
>   final String fullName = ...
> [constructor]
> }
> 
> And now let's assume that - as you could expect - most Person
> instances have the same value for the nationality String, but a
> different name.
> 
> I want to define a custom Externalizer for my type, but the current
> Externalizer API doesn't allow to refer to some common application
> context, which might be extremely useful to deserialize this Person
> instance:
> 
> we could avoid filling the memory of my Grid by having multiple copies
> of the nationality String repeated all over, when a String [1] could
> be reused.
> 
> Would it be a good idea to have the Externalizer instances have an
> initialization phase receiving a ComponentRegistry, so I could look up
> some custom service to de-duplicate or otherwise optimize my in-memory
> data representation?
> Personally I'd prefer to receive it injected via the constructor so
> that I could use a final field when my custom Externalizer is
> constructed.
> 
> This is OGM related.

^ Makes sense, but only solves one part of the problem. 

String is probably a bad example here [as you already said, due to 1], but a better example is if you have a Nationality class with country name, timezone…etc in it.

My point is, your suggestion works for nodes to which data is replicated to, but in the original node where you've created 100 Person instances for Spanish nationaility, you'd still potentially have 100 instances.

Did you have anything in mind for this?

Btw, not sure about the need of ComponentRegistry here. IMO, this kind of feature should work for Hot Rod clients too, where Externalizers might be used in the future, and where there's no ComponentRegistry (unless it's a RemoteCacheStore...)

> 
> Cheers,
> Sanne
> 
> 
> 1 - or any immutable object: I'm using String as an example so let's
> forget about the static String pool optimizations the JVM might
> enable..
> _______________________________________________
> 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