Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Adding Tree-lock option to CDO editor.
[CDO] Adding Tree-lock option to CDO editor. [message #499090] Thu, 19 November 2009 19:00 Go to next message
Juan Pedro Silva is currently offline Juan Pedro SilvaFriend
Messages: 258
Registered: July 2009
Senior Member
Hi everybody.
We are planning to add a tree-lock option to the CDO editor.
They would show up in the locking menu, and have two options:
Tree-ReadLock and Tree-WriteLock.
The idea, as it name indicates, is to recursively lock all elements
within a tree.

I started implementing it.
So far I defined two new actions, implementing
AbstractTreeLockObjectsAction, an specialization of
AbstractLockObjectsAction (it overrides "selectionChanged" and changes
the selection to contain the whole tree), and added the actions to
CDOActionBarContributor.
I also defined two new Locktypes (TREE_READ and TREE_WRITE) in
IRWLockManager. I make them use the read and write LockStrategy
respectively.

The locking/unlocking works fine (single threaded), but when I open the
locking menu again, not only the correspondent option is checked, but
also a couple of more (both tree locks and read lock) for all elements
in the tree. Which could be the cause of this, and how could I correct
it so that only the proper tree lock is checked?. I may be using the
same id or something, because when I select read lock all three are
checked again. However, I double-checked and every definition has its
own id and locktype.

What really brings me here, and what I would really appreciate, are your
comments on the possible synchronization issues of the approach. Which
measures should I take when trying to lock a tree?.
I see I should have something similar to a tryLock() method for trees,
and a rollback. What I'm most concerned about is that, having large
trees, a different transaction may get a lock of an element within the
tree once the lock-tree has been requested, and so invalidate the
process and force a rollback. Is there a more adequate way of
approaching this?, getting a lock of the whole model beforehand could be
a possibility (you are sure the tree-lock acquisition can be fulfilled),
but you may not get this lock even though you could be able to lock the
tree you are interested in (i.e. when another view has a lock of an
element from the same resource but from a different tree). Am I missing
any other important issues?.

I look forward to your comments.
Best regards,
Juan Pedro
Re: [CDO] Adding Tree-lock option to CDO editor. [message #499123 is a reply to message #499090] Thu, 19 November 2009 23:24 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6454
Registered: July 2009
Senior Member
Hi Juan Pedro,

Comments below...


Juan Pedro Silva schrieb:
> Hi everybody.
> We are planning to add a tree-lock option to the CDO editor.
I'd assume tree-locking be implemented at the core level first. After
proper API and protocol has been added for that it seems to be a good
idea to make that functionality avaiable in the UI.

> They would show up in the locking menu, and have two options:
> Tree-ReadLock and Tree-WriteLock.
> The idea, as it name indicates, is to recursively lock all elements
> within a tree.
>
> I started implementing it.
> So far I defined two new actions, implementing
> AbstractTreeLockObjectsAction, an specialization of
> AbstractLockObjectsAction (it overrides "selectionChanged" and changes
> the selection to contain the whole tree), and added the actions to
> CDOActionBarContributor.
> I also defined two new Locktypes (TREE_READ and TREE_WRITE) in
> IRWLockManager. I make them use the read and write LockStrategy
> respectively.
I'm not sure this little piece of information is enough for me to fully
understand how you are trying to solve this. I think generally there are
two different approaches possible:

1) One with new lock types that apply to the root of the sub tree that
you want to lock.

2) One that just uses the existing lock types but atomically applies
them to all nodes in a sub tree.

Both have their pros and cons. Performance impact seems crucial in the
decision for one or the other approach. I have the feeling that approach
2) is way simpler to implement and accumulates most of the runtime cost
at the time locks are acquired or released, instead of impacting all
other read and write operations.

>
> The locking/unlocking works fine (single threaded), but when I open
> the locking menu again, not only the correspondent option is checked,
> but also a couple of more (both tree locks and read lock) for all
> elements in the tree. Which could be the cause of this, and how could
> I correct it so that only the proper tree lock is checked?. I may be
> using the same id or something, because when I select read lock all
> three are checked again. However, I double-checked and every
> definition has its own id and locktype.
>
> What really brings me here, and what I would really appreciate, are
> your comments on the possible synchronization issues of the approach.
> Which measures should I take when trying to lock a tree?.
I can not give you a simple recipe for that. The reason that we did not
consider to provide this functionality is that it is very hard to do it
right. Personally I prefer to have some logic in the application that
recognizes some custom rules that make it possible to lock a tree with a
single physical lock.

> I see I should have something similar to a tryLock() method for trees,
> and a rollback.
> What I'm most concerned about is that, having large trees, a different
> transaction may get a lock of an element within the tree once the
> lock-tree has been requested, and so invalidate the process and force
> a rollback. Is there a more adequate way of approaching this?, getting
> a lock of the whole model beforehand could be a possibility (you are
> sure the tree-lock acquisition can be fulfilled), but you may not get
> this lock even though you could be able to lock the tree you are
> interested in (i.e. when another view has a lock of an element from
> the same resource but from a different tree). Am I missing any other
> important issues?.
You see that a whole bunch of problems have to be addressed. A good
design and a correct and performant implementation of this functionality
could easily take up some weeks. Unfortunately I see currently no way to
do this for you unless you fund this work. If you have a design and
exactly describe it, I could tell you if it's good or not. If you have
an implementation I could review it. Please attach it to a bugzilla.

Cheers
/Eike

----
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Re: [CDO] Adding Tree-lock option to CDO editor. [message #499183 is a reply to message #499090] Fri, 20 November 2009 10:39 Go to previous messageGo to next message
Juan Pedro Silva is currently offline Juan Pedro SilvaFriend
Messages: 258
Registered: July 2009
Senior Member
Hi Eike.
Thanks for your answer.
We are taking the 2nd approach you describe, and use the available lock API for all elements in a tree (we just change the selection to hold a collection of objects instead of just the first object). That is why I started playing with the UI part right away.

Regarding your comment on the application-level single lock for a whole tree, I feel vulnerable to the use of the default editor in other view, for instance, that would allow the editing of elements as it doesn't know of this kind of lock. I'll check with the interested party.

Regretfully, there is no funding available for this, as it is a research initiative. I'll keep maturing our current implementation and create an enhancement bug as soon as it reaches a acceptable level.

Thanks again,
Juan Pedro


Hi Juan Pedro,

Comments below...


Juan Pedro Silva schrieb:
> Hi everybody.
> We are planning to add a tree-lock option to the CDO editor.
I'd assume tree-locking be implemented at the core level first. After proper API and protocol has been added for that it seems to be a good idea to make that functionality avaiable in the UI.

> They would show up in the locking menu, and have two options:
> Tree-ReadLock and Tree-WriteLock.
> The idea, as it name indicates, is to recursively lock all elements
> within a tree.
>
> I started implementing it.
> So far I defined two new actions, implementing
> AbstractTreeLockObjectsAction, an specialization of
> AbstractLockObjectsAction (it overrides "selectionChanged" and changes
> the selection to contain the whole tree), and added the actions to
> CDOActionBarContributor.
> I also defined two new Locktypes (TREE_READ and TREE_WRITE) in
> IRWLockManager. I make them use the read and write LockStrategy
> respectively.
I'm not sure this little piece of information is enough for me to fully understand how you are trying to solve this. I think generally there are two different approaches possible:

1) One with new lock types that apply to the root of the sub tree that
you want to lock.

2) One that just uses the existing lock types but atomically applies them to all nodes in a sub tree.

Both have their pros and cons. Performance impact seems crucial in the
decision for one or the other approach. I have the feeling that approach
2) is way simpler to implement and accumulates most of the runtime cost
at the time locks are acquired or released, instead of impacting all
other read and write operations.

>
> The locking/unlocking works fine (single threaded), but when I open
> the locking menu again, not only the correspondent option is checked,
> but also a couple of more (both tree locks and read lock) for all
> elements in the tree. Which could be the cause of this, and how could
> I correct it so that only the proper tree lock is checked?. I may be
> using the same id or something, because when I select read lock all
> three are checked again. However, I double-checked and every
> definition has its own id and locktype.
>
> What really brings me here, and what I would really appreciate, are
> your comments on the possible synchronization issues of the approach.
> Which measures should I take when trying to lock a tree?.
I can not give you a simple recipe for that. The reason that we did not consider to provide this functionality is that it is very hard to do it right. Personally I prefer to have some logic in the application that recognizes some custom rules that make it possible to lock a tree with a single physical lock.

> I see I should have something similar to a tryLock() method for trees,
> and a rollback.
> What I'm most concerned about is that, having large trees, a different
> transaction may get a lock of an element within the tree once the
> lock-tree has been requested, and so invalidate the process and force
> a rollback. Is there a more adequate way of approaching this?, getting
> a lock of the whole model beforehand could be a possibility (you are
> sure the tree-lock acquisition can be fulfilled), but you may not get
> this lock even though you could be able to lock the tree you are
> interested in (i.e. when another view has a lock of an element from
> the same resource but from a different tree). Am I missing any other
> important issues?.
You see that a whole bunch of problems have to be addressed. A good design and a correct and performant implementation of this functionality could easily take up some weeks. Unfortunately I see currently no way todo this for you unless you fund this work. If you have a design and exactly describe it, I could tell you if it's good or not. If you have an implementation I could review it. Please attach it to a bugzilla.

Cheers
/Eike
Re: [CDO] Adding Tree-lock option to CDO editor. [message #500513 is a reply to message #499123] Thu, 26 November 2009 13:31 Go to previous message
Juan Pedro Silva is currently offline Juan Pedro SilvaFriend
Messages: 258
Registered: July 2009
Senior Member
Eike,
I just attached a first working implementation to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=270393 to get the
discussion going. It's working fine (as far as I know), and it may be
enough for us.

I also found a minor bug in the process:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=296225
It has been fixed in my implementation, and I also described the
solution I used in the comments of the bug.

I will soon upload a new lock-notification patch, as I now have a more
clear idea on how to improve it.
Regards,
Juan Pedro


Eike Stepper escribió:
> Hi Juan Pedro,
>
> Comments below...
>
>
> Juan Pedro Silva schrieb:
>> Hi everybody.
>> We are planning to add a tree-lock option to the CDO editor.
> I'd assume tree-locking be implemented at the core level first. After
> proper API and protocol has been added for that it seems to be a good
> idea to make that functionality avaiable in the UI.
>
>> They would show up in the locking menu, and have two options:
>> Tree-ReadLock and Tree-WriteLock.
>> The idea, as it name indicates, is to recursively lock all elements
>> within a tree.
>>
>> I started implementing it.
>> So far I defined two new actions, implementing
>> AbstractTreeLockObjectsAction, an specialization of
>> AbstractLockObjectsAction (it overrides "selectionChanged" and changes
>> the selection to contain the whole tree), and added the actions to
>> CDOActionBarContributor.
>> I also defined two new Locktypes (TREE_READ and TREE_WRITE) in
>> IRWLockManager. I make them use the read and write LockStrategy
>> respectively.
> I'm not sure this little piece of information is enough for me to fully
> understand how you are trying to solve this. I think generally there are
> two different approaches possible:
>
> 1) One with new lock types that apply to the root of the sub tree that
> you want to lock.
>
> 2) One that just uses the existing lock types but atomically applies
> them to all nodes in a sub tree.
>
> Both have their pros and cons. Performance impact seems crucial in the
> decision for one or the other approach. I have the feeling that approach
> 2) is way simpler to implement and accumulates most of the runtime cost
> at the time locks are acquired or released, instead of impacting all
> other read and write operations.
>
>>
>> The locking/unlocking works fine (single threaded), but when I open
>> the locking menu again, not only the correspondent option is checked,
>> but also a couple of more (both tree locks and read lock) for all
>> elements in the tree. Which could be the cause of this, and how could
>> I correct it so that only the proper tree lock is checked?. I may be
>> using the same id or something, because when I select read lock all
>> three are checked again. However, I double-checked and every
>> definition has its own id and locktype.
>>
>> What really brings me here, and what I would really appreciate, are
>> your comments on the possible synchronization issues of the approach.
>> Which measures should I take when trying to lock a tree?.
> I can not give you a simple recipe for that. The reason that we did not
> consider to provide this functionality is that it is very hard to do it
> right. Personally I prefer to have some logic in the application that
> recognizes some custom rules that make it possible to lock a tree with a
> single physical lock.
>
>> I see I should have something similar to a tryLock() method for trees,
>> and a rollback.
>> What I'm most concerned about is that, having large trees, a different
>> transaction may get a lock of an element within the tree once the
>> lock-tree has been requested, and so invalidate the process and force
>> a rollback. Is there a more adequate way of approaching this?, getting
>> a lock of the whole model beforehand could be a possibility (you are
>> sure the tree-lock acquisition can be fulfilled), but you may not get
>> this lock even though you could be able to lock the tree you are
>> interested in (i.e. when another view has a lock of an element from
>> the same resource but from a different tree). Am I missing any other
>> important issues?.
> You see that a whole bunch of problems have to be addressed. A good
> design and a correct and performant implementation of this functionality
> could easily take up some weeks. Unfortunately I see currently no way to
> do this for you unless you fund this work. If you have a design and
> exactly describe it, I could tell you if it's good or not. If you have
> an implementation I could review it. Please attach it to a bugzilla.
>
> Cheers
> /Eike
>
> ----
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
Previous Topic:EObject to XML
Next Topic:[CDO] resolving conflicts with commands
Goto Forum:
  


Current Time: Sat Nov 23 02:19:41 GMT 2019

Powered by FUDForum. Page generated in 0.01964 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top