Hi Isuru, I think we need to be little careful when doing this, because the reason for locking the complete tree at the root level was that we wanted to make sure that operations that read the topology consider a snapshot of the tree to take a decision.
If we manage locks in the middle of the tree, there is a possibility that the topology may change while a process is traversing through it to execute an operation. Thanks On Fri, Oct 3, 2014 at 3:05 PM, Isuru Haththotuwa <isu...@apache.org> wrote: > I did the initial changes, at the testing phase now. For an example, if we > need to add a new Service, we do not need to lock everything now. We an > only acquire the write lock on Services, and add the Service. If we need to > modify a particular Service, can read lock the Services and acquire the > write lock on the relevant Service and do the modification. This support is > there for Services, Cluster and Applications. > > On Wed, Oct 1, 2014 at 9:27 PM, Manula Chathurika Thantriwatte < > manu...@wso2.com> wrote: > >> 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/ >> >> -- >> <http://manulachathurika.blogspot.com/> >> Thanks and Regards, >> >> Isuru H. >> <http://manulachathurika.blogspot.com/> >> +94 716 358 048 <http://manulachathurika.blogspot.com/>* >> <http://wso2.com/>* >> >> >> * <http://wso2.com/>* >> >> >> -- Imesh Gunaratne Technical Lead, WSO2 Committer & PMC Member, Apache Stratos
