Nicely done! On 10 Nov 2010, at 16:53, Galder Zamarreño wrote: > I've just finished writing http://community.jboss.org/docs/DOC-16081 > > Anything that should change? Anything extra that should be included? > > Scott, I believe you've played quite a bit with the tree module, so it'd be great to hear your feedback as a user :). Maybe we should add a section to explain when it makes sense to use the tree module API, i.e. to build a JNDI repo? > > Cheers, > -- > Galder Zamarreño > Sr. Software Engineer > Infinispan, JBoss Cache > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org&gt; 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(a)jboss.org >> Lead, Infinispan >> Lead, JBoss Cache >> http://www.infinispan.org >> http://www.jbosscache.org >> >> >> >> >> >> _______________________________________________ >> infinispan-dev mailing list >> infinispan-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev >> > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

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(a)jboss.org&gt; 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(a)jboss.org&gt; 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(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev

On 26 Nov 2010, at 16:06, Eduardo Martins wrote: > 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? Yup. -- Manik Surtani manik(a)jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org _______________________________________________ infinispan-dev mailing list infinispan-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev