Re: [infinispan-dev] Providing a context for object de-serialization
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache