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  |
 Juan Pedro Silva
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  |
|
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
Cheers
/Eike
----
http://www.esc-net.de
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 |
Juan Pedro Silva
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 |
Juan Pedro Silva
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
|
|
|
Goto Forum:
Current Time: Fri Apr 26 18:22:50 GMT 2024
Powered by FUDForum. Page generated in 0.03111 seconds |
] 
Search
Help
Register
Login
Home
