stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Imesh Gunaratne <im...@apache.org>
Subject Re: [Discuss] Hierarchical Locking for Topology
Date Sat, 04 Oct 2014 17:22:25 GMT
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 <isuruh@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 <
> manulac@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 <isuruh@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 : manulac@wso2.com / manula@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

Mime
View raw message