[infinispan-dev] Potential for context object for serial/deserial in marshalling rework

[William Burns]

On Thu, Apr 21, 2016 at 4:35 AM Galder Zamarreño <galder at redhat.com> wrote:

> For example, I'd like to get some clarification on the scope of the
> context object:
>
> @Will, will the solution you provided in [2] deal with multiple JGroups
> marshalling request callbacks? Or is it only designed for a single
> marshalling request callback coming from JGroups tgat contains a
> CacheStatusResponse map? Since it's a thread local is not easy to see
> what's the lifespan of these instances stored in the thread local...
>

The scope is per object serialization instance (the thread local is always
cleared after each object).  More specifically, the externalizer was meant
to be extended by possibly different classes and the first class in the
marshalling "stack" will set the thread local to have the IdentityMap.  It
then uses that to map objects that have the same instance to be serialized.

JBoss Marshalling does the same thing internally when you don't use an
object table btw.


>
> The simplest thing would be to have a new context created for each JGroups
> marshalling request.
>
> However, more optimizations could be achieved from:
>
> 1. For non-transaction operations, a context per operation. So if a
> cache.put() results in two operations being serialized (get to return
> previous value, and put itself), then the context could expand those two
> serializations.
>
> 2. For transaction operations, a context per transaction.
>
> @Sanne, would this be enough for you? In your [4] dev post you seem to
> want to go beyond marshalling into how we'd keep references of objects in
> memory, e.g. if a String is repeated in many places, have a way to
> centralise that storage in memory itself.
>
> Cheers,
>
> [4] http://lists.jboss.org/pipermail/infinispan-dev/2012-June/010925.html
> --
> Galder Zamarreño
> Infinispan, Red Hat
>
> > On 21 Apr 2016, at 10:07, Galder Zamarreño <galder at redhat.com> wrote:
> >
> > Hey guys,
> >
> > Just a quick heads up about [1].
> >
> > As I was looking at the marshalling code in core, I spotted the work
> done for [2] and by extension [3].
> >
> > I can certainly see the practicality of Will's solution in [2] which
> fitted quite well with the current marshalling architecture, but as we
> rethink the entire marshalling layer in [1], I'm wondering if a
> context-object where we can track repeated fields like Strings,
> Addresses... would be more suitable. For starters, we'd get rid of thread
> locals and could be more easily exposed in other places.
> >
> > Any ideas or updates you have on the topic please let me know.
> >
> > Cheers,
> >
> > [1] https://issues.jboss.org/browse/ISPN-6498
> > [2] https://issues.jboss.org/browse/ISPN-4979
> > [3] https://issues.jboss.org/browse/ISPN-2133
> > --
> > Galder Zamarreño
> > Infinispan, Red Hat
> >
> >
> > _______________________________________________
> > 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20160421/08e49989/attachment-0001.html