Hi Isuru, +1 for the hierarchical locking approach. Using hierarchical locking we can have more benefits [1].
[1] http://synapticnulship.com/blog/2013/03/08/comparison-chainlocker-vs-heirarchical-mutexes/ On Wed, Oct 1, 2014 at 7:46 PM, Isuru Haththotuwa <isu...@apache.org> wrote: > Hi Devs, > > In the current Topology implementation, we acquire read/write locks on > Topology from the root level itself. For an example, if we need to modify a > single Cluster object, we still need to acquire a write lock from the > Topology root level. But, this is a costly operation. Specially, with > Service Grouping changes, we would need to traverse through an Application. > Since an Application can be a recursive structure, it can be a time > consuming operation. in such a scenario, if we are to lock the whole > Topology, there will be many threads waiting on that lock. > > As a solution, I think we can use hierarchical locking [1]. For an > example, when you need to obtain the write lock for a particular > Application, you do not need to lock the whole tree, but can lock only that > Application itself. However, still we need to get the read locks for the > parents. > > A separate Lock tree will be maintained for the Topology. > > Please share your feedback. > > [1]. > http://collaboration.cmc.ec.gc.ca/science/rpn/biblio/ddj/Website/articles/DDJ/2008/0801/071201hs01/071201hs01.html > > -- > Thanks and Regards, > > Isuru H. > +94 716 358 048* <http://wso2.com/>* > > > -- Regards, Manula Chathurika Thantriwatte Software Engineer WSO2 Inc. : http://wso2.com lean . enterprise . middleware email : manu...@wso2.com / man...@apache.org phone : +94 772492511 blog : http://manulachathurika.blogspot.com/