[infinispan-dev] Tree API module wiki

[Eduardo Martins]

Gave it a first look, so each node is stored in Cache by 2 atomic
maps, one for holding childs, another for data, both pointed by fqn
and a type enum. Am I getting it correctly?

-- Eduardo
..............................................
http://emmartins.blogspot.com
http://redhat.com/solutions/telco



On Fri, Nov 26, 2010 at 2:10 PM, Manik Surtani <manik at jboss.org> wrote:
>
> On 26 Nov 2010, at 14:06, Eduardo Martins wrote:
>
> Currently JBoss Cache (along with JTA) is what is holding off
> Mobicents performance improvements, a profiling session will put
> everything related with JBC interaction as top hotspots. Note that
> currently performance is not bad at all, we are at same level as
> competition but in this business, and unlike Java EE, latency and
> throughput is all that matters.
>
> Tell me more about this indirection/references layer, since I believe
> no locks on child insert/removals will be a must. Also note that we
> will need to keep a transaction isolation similar to what JBoss Cache
> provides now, so 2 parallel child inserts/removals must be handled
> correctly at JTA level too, dunno if it matters at all but just want
> to define what are the requirements.
>
> Well, step 1 should be for you to have a look at the srcs of the Tree module
> and see how it breaks up tree structured data into flat data.  If this is
> what you would have done manually anyway, then it's already done for you.
>  :-)
> https://github.com/infinispan/infinispan/tree/master/tree/
>
> -- Eduardo
> ..............................................
> http://emmartins.blogspot.com
> http://redhat.com/solutions/telco
>
> On Fri, Nov 26, 2010 at 1:54 PM, Manik Surtani <manik at jboss.org> wrote:
>
> On 26 Nov 2010, at 13:38, Eduardo Martins wrote:
>
> You mean we will get 5-10% if implementing the parent, child relations
>
> ourselves, where needed?
>
> Maybe.  Since some of the relationships could be denormalized/flattened,
> etc.
>
> That would for sure be worth the data model
>
> rework.
>
> Depends.  How much of your time is spent in the data grid?  5%?  So 5% x 5%
> = overall 0.25% gain?  :-)
>
> The child relation would be done using a cache map entry with
>
> a set/array value? If yes wouldn't that lock the parent on each child
>
> insert/removal?
>
> Yes.  Or you could use a layer of indirection/references which will then not
> lock the hierarchy.
>
>
> -- Eduardo
>
> ..............................................
>
> http://emmartins.blogspot.com
>
> http://redhat.com/solutions/telco
>
>
> On Fri, Nov 26, 2010 at 1:05 PM, Manik Surtani <manik at jboss.org> wrote:
>
> On 25 Nov 2010, at 03:24, Eduardo Martins wrote:
>
> Great, finally an easy migration from JBoss Cache.
>
> Just to know our options in Mobicents future, are there any cons on
>
> using this API? Is there a reason to change a data model/schema coming
>
> from JBoss Cache, that really takes advantage of node relations
>
> parent/child? For instance it's very common to retrieve the set of
>
> childs for a node, another common usage is the removal for a complete
>
> subtree. We have time to rework this data model if it's not the best
>
> usage, we want it as fast as possible, both local and cluster/cloud
>
> modes.
>
> There is nothing wrong with using the Tree API, except that it doesn't
> perform as well as the flat API.  Now don't let this scare you off - in
> terms of performance, we're talking 5 ~ 10% and if the API works better for
> you, then use it.  But you should benchmark for yourself and see whether you
> need to extract this extra performance in exchange for reworking your data
> model.  YMMV.  :-)
>
> Cheers
>
> Manik
>
> --
>
> Manik Surtani
>
> manik at jboss.org
>
> Lead, Infinispan
>
> Lead, JBoss Cache
>
> http://www.infinispan.org
>
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
>
> 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
>
> --
>
> Manik Surtani
>
> manik at jboss.org
>
> Lead, Infinispan
>
> Lead, JBoss Cache
>
> http://www.infinispan.org
>
> http://www.jbosscache.org
>
>
>
>
>
> _______________________________________________
>
> 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
>
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>