Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] Pessimistic lock with EMF Transaction
[CDO] Pessimistic lock with EMF Transaction [message #897810] Wed, 25 July 2012 09:31 Go to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi,

In our use case, where we manages ourself locks (with
CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
pessimistic lock strategy using the EMF Transaction framework to avoid
conflict, we have cases where we can yet have conflict.

I explain first the architecture and the workflow.

We use a TransactionalEditingDomain and we have a
ResourceSetListenerImpl, we will call it Locker. On each CDOObject
change, through a EMF Command, the Locker check if one of the CDOObjects
is already locked by another user, if true the Locker throws a
RollbackException to undo the changes done during the EMF Command, if no
changed CDOObjects was already locked by another user then we allow the
changes and lock all changed CDOObjects and send a remote message
(CDORemoteSessionMessage) to indicate to all other users
(CDORemoteSession) the locked CDOObjects with a
RemoteMessageNotificationRequest.

After the user having done the changes save its changes, we commit and
just after we send a unlock message also through a
RemoteMessageNotificationRequest. Like that the other users update their
cache of locked objects by other, and are allowed to do changes.

The attached screenshot2.png show the normal workflow.

But the issue comes from the fact that RemoteMessageNotificationRequest
and CommitTransactionRequest are not sync, then remote users can
receives the unlock message before the InvalidationRunnable execution,
between the unlock message and the InvalidationRunnable execution,
remote users can do changes without being rollback by the Locker then we
come to a conflict.

The attached screenshot.png show the conflicting workflow.
This last image show that on user2 the invalidation
(InvalidationRunnable) is executed after the unlock message reception
then between these 2 events user2 have the permission to do model
changes like the CDOObjects are unlocked. But during the
InvalidationRunnable execution, some conflicts are detected and can't be
resolved then at the end user2 can't save its shared resource (CDOResource).

I don't know how to ensure that the InvalidationRunnable be done before
the unlock on the CDOServer and before the unlock message reception?

We have think about using the timestamp returned by the
CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
message then when the user2 receives the unlock message it wait a
CDOViewAdaptersNotifiedEvent with the correct timestamp from the
InvalidationRunnable.

What do you think about this last solution?

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #897910 is a reply to message #897810] Wed, 25 July 2012 12:19 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Hi Esteban,

The lock notifications distributed by CDO 4.1 should fix this problem or do I misunderstand it?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
> Hi,
>
> In our use case, where we manages ourself locks (with CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we
> use pessimistic lock strategy using the EMF Transaction framework to avoid conflict, we have cases where we can yet
> have conflict.
>
> I explain first the architecture and the workflow.
>
> We use a TransactionalEditingDomain and we have a ResourceSetListenerImpl, we will call it Locker. On each CDOObject
> change, through a EMF Command, the Locker check if one of the CDOObjects is already locked by another user, if true
> the Locker throws a RollbackException to undo the changes done during the EMF Command, if no changed CDOObjects was
> already locked by another user then we allow the changes and lock all changed CDOObjects and send a remote message
> (CDORemoteSessionMessage) to indicate to all other users (CDORemoteSession) the locked CDOObjects with a
> RemoteMessageNotificationRequest.
>
> After the user having done the changes save its changes, we commit and just after we send a unlock message also
> through a RemoteMessageNotificationRequest. Like that the other users update their cache of locked objects by other,
> and are allowed to do changes.
>
> The attached screenshot2.png show the normal workflow.
>
> But the issue comes from the fact that RemoteMessageNotificationRequest and CommitTransactionRequest are not sync,
> then remote users can receives the unlock message before the InvalidationRunnable execution, between the unlock
> message and the InvalidationRunnable execution, remote users can do changes without being rollback by the Locker then
> we come to a conflict.
>
> The attached screenshot.png show the conflicting workflow.
> This last image show that on user2 the invalidation (InvalidationRunnable) is executed after the unlock message
> reception then between these 2 events user2 have the permission to do model changes like the CDOObjects are unlocked.
> But during the InvalidationRunnable execution, some conflicts are detected and can't be resolved then at the end user2
> can't save its shared resource (CDOResource).
>
> I don't know how to ensure that the InvalidationRunnable be done before the unlock on the CDOServer and before the
> unlock message reception?
>
> We have think about using the timestamp returned by the CDOTransaction.commit()::CDOCommitInfo and send it with the
> unlock message then when the user2 receives the unlock message it wait a CDOViewAdaptersNotifiedEvent with the correct
> timestamp from the InvalidationRunnable.
>
> What do you think about this last solution?
>
> Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #898004 is a reply to message #897910] Wed, 25 July 2012 15:20 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi,

Do you have a bugzilla about this lock notifications in 4.1?
Also there is a news and noteworthy about the release 4.1?

Best Regards.

On 25/07/2012 14:19, Eike Stepper wrote:
> Hi Esteban,
>
> The lock notifications distributed by CDO 4.1 should fix this problem or
> do I misunderstand it?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>> Hi,
>>
>> In our use case, where we manages ourself locks (with
>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>> pessimistic lock strategy using the EMF Transaction framework to avoid
>> conflict, we have cases where we can yet have conflict.
>>
>> I explain first the architecture and the workflow.
>>
>> We use a TransactionalEditingDomain and we have a
>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>> change, through a EMF Command, the Locker check if one of the
>> CDOObjects is already locked by another user, if true the Locker
>> throws a RollbackException to undo the changes done during the EMF
>> Command, if no changed CDOObjects was already locked by another user
>> then we allow the changes and lock all changed CDOObjects and send a
>> remote message (CDORemoteSessionMessage) to indicate to all other
>> users (CDORemoteSession) the locked CDOObjects with a
>> RemoteMessageNotificationRequest.
>>
>> After the user having done the changes save its changes, we commit and
>> just after we send a unlock message also through a
>> RemoteMessageNotificationRequest. Like that the other users update
>> their cache of locked objects by other, and are allowed to do changes.
>>
>> The attached screenshot2.png show the normal workflow.
>>
>> But the issue comes from the fact that
>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>> sync, then remote users can receives the unlock message before the
>> InvalidationRunnable execution, between the unlock message and the
>> InvalidationRunnable execution, remote users can do changes without
>> being rollback by the Locker then we come to a conflict.
>>
>> The attached screenshot.png show the conflicting workflow.
>> This last image show that on user2 the invalidation
>> (InvalidationRunnable) is executed after the unlock message reception
>> then between these 2 events user2 have the permission to do model
>> changes like the CDOObjects are unlocked. But during the
>> InvalidationRunnable execution, some conflicts are detected and can't
>> be resolved then at the end user2 can't save its shared resource
>> (CDOResource).
>>
>> I don't know how to ensure that the InvalidationRunnable be done
>> before the unlock on the CDOServer and before the unlock message
>> reception?
>>
>> We have think about using the timestamp returned by the
>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>> message then when the user2 receives the unlock message it wait a
>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>> InvalidationRunnable.
>>
>> What do you think about this last solution?
>>
>> Best Regards.
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #898058 is a reply to message #898004] Wed, 25 July 2012 17:20 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Am 25.07.2012 17:20, schrieb Esteban Dugueperoux:
> Hi,
>
> Do you have a bugzilla about this lock notifications in 4.1?
Sure. See below...
///
/
> Also there is a news and noteworthy about the release 4.1?
Sure. And it's pretty: http://download.eclipse.org/modeling/emf/cdo/drops/R20120612-1449/relnotes.html

See [353691 <https://bugs.eclipse.org/353691>] Add lock notifications and lock caching /(resolved-fixed in 4.1)

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


/
>
> Best Regards.
>
> On 25/07/2012 14:19, Eike Stepper wrote:
>> Hi Esteban,
>>
>> The lock notifications distributed by CDO 4.1 should fix this problem or
>> do I misunderstand it?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>>> Hi,
>>>
>>> In our use case, where we manages ourself locks (with
>>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>>> pessimistic lock strategy using the EMF Transaction framework to avoid
>>> conflict, we have cases where we can yet have conflict.
>>>
>>> I explain first the architecture and the workflow.
>>>
>>> We use a TransactionalEditingDomain and we have a
>>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>>> change, through a EMF Command, the Locker check if one of the
>>> CDOObjects is already locked by another user, if true the Locker
>>> throws a RollbackException to undo the changes done during the EMF
>>> Command, if no changed CDOObjects was already locked by another user
>>> then we allow the changes and lock all changed CDOObjects and send a
>>> remote message (CDORemoteSessionMessage) to indicate to all other
>>> users (CDORemoteSession) the locked CDOObjects with a
>>> RemoteMessageNotificationRequest.
>>>
>>> After the user having done the changes save its changes, we commit and
>>> just after we send a unlock message also through a
>>> RemoteMessageNotificationRequest. Like that the other users update
>>> their cache of locked objects by other, and are allowed to do changes.
>>>
>>> The attached screenshot2.png show the normal workflow.
>>>
>>> But the issue comes from the fact that
>>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>>> sync, then remote users can receives the unlock message before the
>>> InvalidationRunnable execution, between the unlock message and the
>>> InvalidationRunnable execution, remote users can do changes without
>>> being rollback by the Locker then we come to a conflict.
>>>
>>> The attached screenshot.png show the conflicting workflow.
>>> This last image show that on user2 the invalidation
>>> (InvalidationRunnable) is executed after the unlock message reception
>>> then between these 2 events user2 have the permission to do model
>>> changes like the CDOObjects are unlocked. But during the
>>> InvalidationRunnable execution, some conflicts are detected and can't
>>> be resolved then at the end user2 can't save its shared resource
>>> (CDOResource).
>>>
>>> I don't know how to ensure that the InvalidationRunnable be done
>>> before the unlock on the CDOServer and before the unlock message
>>> reception?
>>>
>>> We have think about using the timestamp returned by the
>>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>>> message then when the user2 receives the unlock message it wait a
>>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>>> InvalidationRunnable.
>>>
>>> What do you think about this last solution?
>>>
>>> Best Regards.
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899108 is a reply to message #898058] Mon, 30 July 2012 15:03 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have seen the new lock notification in CDO 4.1, but it doesn't solve
our issue, in our use case to avoid conflict, we want to have a commit
request followed by a unlock request be atomic and ordered but currently
with our use case having many users commiting their changes in a short
time, a unlock request can be managed by the server before a commit
request, especially with the invalidation step at remote users.
Do you know a mean to have CDOTransaction.commit() call blocked until
all remote users clients have their invalidation step done? Like that we
could unlocks CDOObjects after the commit to allow remote users do
changes without conflicts.

P.S. : I have attached a JUnit test case to show in debug the issue,
putting a breakpoint in InvalidationRunnable to retain the main user
changes integration and leaves the remote user do its changes, debug
step by step the InvalidationRunnable previously stopped and we can see
conflicts, the remote user is allowed to do changes because the
"user1Locker.unlock();" has been executed just after the commit
"user1CDOTransaction.commit();".

Best Regards.

On 25/07/2012 19:20, Eike Stepper wrote:
> Am 25.07.2012 17:20, schrieb Esteban Dugueperoux:
>> Hi,
>>
>> Do you have a bugzilla about this lock notifications in 4.1?
> Sure. See below...
> ///
> /
>> Also there is a news and noteworthy about the release 4.1?
> Sure. And it's pretty:
> http://download.eclipse.org/modeling/emf/cdo/drops/R20120612-1449/relnotes.html
>
>
> See [353691 <https://bugs.eclipse.org/353691>] Add lock notifications
> and lock caching /(resolved-fixed in 4.1)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> /
>>
>> Best Regards.
>>
>> On 25/07/2012 14:19, Eike Stepper wrote:
>>> Hi Esteban,
>>>
>>> The lock notifications distributed by CDO 4.1 should fix this problem or
>>> do I misunderstand it?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>>>> Hi,
>>>>
>>>> In our use case, where we manages ourself locks (with
>>>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>>>> pessimistic lock strategy using the EMF Transaction framework to avoid
>>>> conflict, we have cases where we can yet have conflict.
>>>>
>>>> I explain first the architecture and the workflow.
>>>>
>>>> We use a TransactionalEditingDomain and we have a
>>>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>>>> change, through a EMF Command, the Locker check if one of the
>>>> CDOObjects is already locked by another user, if true the Locker
>>>> throws a RollbackException to undo the changes done during the EMF
>>>> Command, if no changed CDOObjects was already locked by another user
>>>> then we allow the changes and lock all changed CDOObjects and send a
>>>> remote message (CDORemoteSessionMessage) to indicate to all other
>>>> users (CDORemoteSession) the locked CDOObjects with a
>>>> RemoteMessageNotificationRequest.
>>>>
>>>> After the user having done the changes save its changes, we commit and
>>>> just after we send a unlock message also through a
>>>> RemoteMessageNotificationRequest. Like that the other users update
>>>> their cache of locked objects by other, and are allowed to do changes.
>>>>
>>>> The attached screenshot2.png show the normal workflow.
>>>>
>>>> But the issue comes from the fact that
>>>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>>>> sync, then remote users can receives the unlock message before the
>>>> InvalidationRunnable execution, between the unlock message and the
>>>> InvalidationRunnable execution, remote users can do changes without
>>>> being rollback by the Locker then we come to a conflict.
>>>>
>>>> The attached screenshot.png show the conflicting workflow.
>>>> This last image show that on user2 the invalidation
>>>> (InvalidationRunnable) is executed after the unlock message reception
>>>> then between these 2 events user2 have the permission to do model
>>>> changes like the CDOObjects are unlocked. But during the
>>>> InvalidationRunnable execution, some conflicts are detected and can't
>>>> be resolved then at the end user2 can't save its shared resource
>>>> (CDOResource).
>>>>
>>>> I don't know how to ensure that the InvalidationRunnable be done
>>>> before the unlock on the CDOServer and before the unlock message
>>>> reception?
>>>>
>>>> We have think about using the timestamp returned by the
>>>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>>>> message then when the user2 receives the unlock message it wait a
>>>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>>>> InvalidationRunnable.
>>>>
>>>> What do you think about this last solution?
>>>>
>>>> Best Regards.
>>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899110 is a reply to message #898058] Mon, 30 July 2012 15:03 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have seen the new lock notification in CDO 4.1, but it doesn't solve
our issue, in our use case to avoid conflict, we want to have a commit
request followed by a unlock request be atomic and ordered but currently
with our use case having many users commiting their changes in a short
time, a unlock request can be managed by the server before a commit
request, especially with the invalidation step at remote users.
Do you know a mean to have CDOTransaction.commit() call blocked until
all remote users clients have their invalidation step done? Like that we
could unlocks CDOObjects after the commit to allow remote users do
changes without conflicts.

P.S. : I have attached a JUnit test case to show in debug the issue,
putting a breakpoint in InvalidationRunnable to retain the main user
changes integration and leaves the remote user do its changes, debug
step by step the InvalidationRunnable previously stopped and we can see
conflicts, the remote user is allowed to do changes because the
"user1Locker.unlock();" has been executed just after the commit
"user1CDOTransaction.commit();".

Best Regards.

On 25/07/2012 19:20, Eike Stepper wrote:
> Am 25.07.2012 17:20, schrieb Esteban Dugueperoux:
>> Hi,
>>
>> Do you have a bugzilla about this lock notifications in 4.1?
> Sure. See below...
> ///
> /
>> Also there is a news and noteworthy about the release 4.1?
> Sure. And it's pretty:
> http://download.eclipse.org/modeling/emf/cdo/drops/R20120612-1449/relnotes.html
>
>
> See [353691 <https://bugs.eclipse.org/353691>] Add lock notifications
> and lock caching /(resolved-fixed in 4.1)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> /
>>
>> Best Regards.
>>
>> On 25/07/2012 14:19, Eike Stepper wrote:
>>> Hi Esteban,
>>>
>>> The lock notifications distributed by CDO 4.1 should fix this problem or
>>> do I misunderstand it?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>>>> Hi,
>>>>
>>>> In our use case, where we manages ourself locks (with
>>>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>>>> pessimistic lock strategy using the EMF Transaction framework to avoid
>>>> conflict, we have cases where we can yet have conflict.
>>>>
>>>> I explain first the architecture and the workflow.
>>>>
>>>> We use a TransactionalEditingDomain and we have a
>>>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>>>> change, through a EMF Command, the Locker check if one of the
>>>> CDOObjects is already locked by another user, if true the Locker
>>>> throws a RollbackException to undo the changes done during the EMF
>>>> Command, if no changed CDOObjects was already locked by another user
>>>> then we allow the changes and lock all changed CDOObjects and send a
>>>> remote message (CDORemoteSessionMessage) to indicate to all other
>>>> users (CDORemoteSession) the locked CDOObjects with a
>>>> RemoteMessageNotificationRequest.
>>>>
>>>> After the user having done the changes save its changes, we commit and
>>>> just after we send a unlock message also through a
>>>> RemoteMessageNotificationRequest. Like that the other users update
>>>> their cache of locked objects by other, and are allowed to do changes.
>>>>
>>>> The attached screenshot2.png show the normal workflow.
>>>>
>>>> But the issue comes from the fact that
>>>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>>>> sync, then remote users can receives the unlock message before the
>>>> InvalidationRunnable execution, between the unlock message and the
>>>> InvalidationRunnable execution, remote users can do changes without
>>>> being rollback by the Locker then we come to a conflict.
>>>>
>>>> The attached screenshot.png show the conflicting workflow.
>>>> This last image show that on user2 the invalidation
>>>> (InvalidationRunnable) is executed after the unlock message reception
>>>> then between these 2 events user2 have the permission to do model
>>>> changes like the CDOObjects are unlocked. But during the
>>>> InvalidationRunnable execution, some conflicts are detected and can't
>>>> be resolved then at the end user2 can't save its shared resource
>>>> (CDOResource).
>>>>
>>>> I don't know how to ensure that the InvalidationRunnable be done
>>>> before the unlock on the CDOServer and before the unlock message
>>>> reception?
>>>>
>>>> We have think about using the timestamp returned by the
>>>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>>>> message then when the user2 receives the unlock message it wait a
>>>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>>>> InvalidationRunnable.
>>>>
>>>> What do you think about this last solution?
>>>>
>>>> Best Regards.
>>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899112 is a reply to message #898058] Mon, 30 July 2012 15:03 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have seen the new lock notification in CDO 4.1, but it doesn't solve
our issue, in our use case to avoid conflict, we want to have a commit
request followed by a unlock request be atomic and ordered but currently
with our use case having many users commiting their changes in a short
time, a unlock request can be managed by the server before a commit
request, especially with the invalidation step at remote users.
Do you know a mean to have CDOTransaction.commit() call blocked until
all remote users clients have their invalidation step done? Like that we
could unlocks CDOObjects after the commit to allow remote users do
changes without conflicts.

P.S. : I have attached a JUnit test case to show in debug the issue,
putting a breakpoint in InvalidationRunnable to retain the main user
changes integration and leaves the remote user do its changes, debug
step by step the InvalidationRunnable previously stopped and we can see
conflicts, the remote user is allowed to do changes because the
"user1Locker.unlock();" has been executed just after the commit
"user1CDOTransaction.commit();".

Best Regards.

On 25/07/2012 19:20, Eike Stepper wrote:
> Am 25.07.2012 17:20, schrieb Esteban Dugueperoux:
>> Hi,
>>
>> Do you have a bugzilla about this lock notifications in 4.1?
> Sure. See below...
> ///
> /
>> Also there is a news and noteworthy about the release 4.1?
> Sure. And it's pretty:
> http://download.eclipse.org/modeling/emf/cdo/drops/R20120612-1449/relnotes.html
>
>
> See [353691 <https://bugs.eclipse.org/353691>] Add lock notifications
> and lock caching /(resolved-fixed in 4.1)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> /
>>
>> Best Regards.
>>
>> On 25/07/2012 14:19, Eike Stepper wrote:
>>> Hi Esteban,
>>>
>>> The lock notifications distributed by CDO 4.1 should fix this problem or
>>> do I misunderstand it?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>>>> Hi,
>>>>
>>>> In our use case, where we manages ourself locks (with
>>>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>>>> pessimistic lock strategy using the EMF Transaction framework to avoid
>>>> conflict, we have cases where we can yet have conflict.
>>>>
>>>> I explain first the architecture and the workflow.
>>>>
>>>> We use a TransactionalEditingDomain and we have a
>>>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>>>> change, through a EMF Command, the Locker check if one of the
>>>> CDOObjects is already locked by another user, if true the Locker
>>>> throws a RollbackException to undo the changes done during the EMF
>>>> Command, if no changed CDOObjects was already locked by another user
>>>> then we allow the changes and lock all changed CDOObjects and send a
>>>> remote message (CDORemoteSessionMessage) to indicate to all other
>>>> users (CDORemoteSession) the locked CDOObjects with a
>>>> RemoteMessageNotificationRequest.
>>>>
>>>> After the user having done the changes save its changes, we commit and
>>>> just after we send a unlock message also through a
>>>> RemoteMessageNotificationRequest. Like that the other users update
>>>> their cache of locked objects by other, and are allowed to do changes.
>>>>
>>>> The attached screenshot2.png show the normal workflow.
>>>>
>>>> But the issue comes from the fact that
>>>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>>>> sync, then remote users can receives the unlock message before the
>>>> InvalidationRunnable execution, between the unlock message and the
>>>> InvalidationRunnable execution, remote users can do changes without
>>>> being rollback by the Locker then we come to a conflict.
>>>>
>>>> The attached screenshot.png show the conflicting workflow.
>>>> This last image show that on user2 the invalidation
>>>> (InvalidationRunnable) is executed after the unlock message reception
>>>> then between these 2 events user2 have the permission to do model
>>>> changes like the CDOObjects are unlocked. But during the
>>>> InvalidationRunnable execution, some conflicts are detected and can't
>>>> be resolved then at the end user2 can't save its shared resource
>>>> (CDOResource).
>>>>
>>>> I don't know how to ensure that the InvalidationRunnable be done
>>>> before the unlock on the CDOServer and before the unlock message
>>>> reception?
>>>>
>>>> We have think about using the timestamp returned by the
>>>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>>>> message then when the user2 receives the unlock message it wait a
>>>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>>>> InvalidationRunnable.
>>>>
>>>> What do you think about this last solution?
>>>>
>>>> Best Regards.
>>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899115 is a reply to message #898058] Mon, 30 July 2012 15:03 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have seen the new lock notification in CDO 4.1, but it doesn't solve
our issue, in our use case to avoid conflict, we want to have a commit
request followed by a unlock request be atomic and ordered but currently
with our use case having many users commiting their changes in a short
time, a unlock request can be managed by the server before a commit
request, especially with the invalidation step at remote users.
Do you know a mean to have CDOTransaction.commit() call blocked until
all remote users clients have their invalidation step done? Like that we
could unlocks CDOObjects after the commit to allow remote users do
changes without conflicts.

P.S. : I have attached a JUnit test case to show in debug the issue,
putting a breakpoint in InvalidationRunnable to retain the main user
changes integration and leaves the remote user do its changes, debug
step by step the InvalidationRunnable previously stopped and we can see
conflicts, the remote user is allowed to do changes because the
"user1Locker.unlock();" has been executed just after the commit
"user1CDOTransaction.commit();".

Best Regards.

On 25/07/2012 19:20, Eike Stepper wrote:
> Am 25.07.2012 17:20, schrieb Esteban Dugueperoux:
>> Hi,
>>
>> Do you have a bugzilla about this lock notifications in 4.1?
> Sure. See below...
> ///
> /
>> Also there is a news and noteworthy about the release 4.1?
> Sure. And it's pretty:
> http://download.eclipse.org/modeling/emf/cdo/drops/R20120612-1449/relnotes.html
>
>
> See [353691 <https://bugs.eclipse.org/353691>] Add lock notifications
> and lock caching /(resolved-fixed in 4.1)
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
> /
>>
>> Best Regards.
>>
>> On 25/07/2012 14:19, Eike Stepper wrote:
>>> Hi Esteban,
>>>
>>> The lock notifications distributed by CDO 4.1 should fix this problem or
>>> do I misunderstand it?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>> Am 25.07.2012 11:31, schrieb Esteban Dugueperoux:
>>>> Hi,
>>>>
>>>> In our use case, where we manages ourself locks (with
>>>> CDOTransaction.options().setAutoReleaseLocksEnabled(false)), we use
>>>> pessimistic lock strategy using the EMF Transaction framework to avoid
>>>> conflict, we have cases where we can yet have conflict.
>>>>
>>>> I explain first the architecture and the workflow.
>>>>
>>>> We use a TransactionalEditingDomain and we have a
>>>> ResourceSetListenerImpl, we will call it Locker. On each CDOObject
>>>> change, through a EMF Command, the Locker check if one of the
>>>> CDOObjects is already locked by another user, if true the Locker
>>>> throws a RollbackException to undo the changes done during the EMF
>>>> Command, if no changed CDOObjects was already locked by another user
>>>> then we allow the changes and lock all changed CDOObjects and send a
>>>> remote message (CDORemoteSessionMessage) to indicate to all other
>>>> users (CDORemoteSession) the locked CDOObjects with a
>>>> RemoteMessageNotificationRequest.
>>>>
>>>> After the user having done the changes save its changes, we commit and
>>>> just after we send a unlock message also through a
>>>> RemoteMessageNotificationRequest. Like that the other users update
>>>> their cache of locked objects by other, and are allowed to do changes.
>>>>
>>>> The attached screenshot2.png show the normal workflow.
>>>>
>>>> But the issue comes from the fact that
>>>> RemoteMessageNotificationRequest and CommitTransactionRequest are not
>>>> sync, then remote users can receives the unlock message before the
>>>> InvalidationRunnable execution, between the unlock message and the
>>>> InvalidationRunnable execution, remote users can do changes without
>>>> being rollback by the Locker then we come to a conflict.
>>>>
>>>> The attached screenshot.png show the conflicting workflow.
>>>> This last image show that on user2 the invalidation
>>>> (InvalidationRunnable) is executed after the unlock message reception
>>>> then between these 2 events user2 have the permission to do model
>>>> changes like the CDOObjects are unlocked. But during the
>>>> InvalidationRunnable execution, some conflicts are detected and can't
>>>> be resolved then at the end user2 can't save its shared resource
>>>> (CDOResource).
>>>>
>>>> I don't know how to ensure that the InvalidationRunnable be done
>>>> before the unlock on the CDOServer and before the unlock message
>>>> reception?
>>>>
>>>> We have think about using the timestamp returned by the
>>>> CDOTransaction.commit()::CDOCommitInfo and send it with the unlock
>>>> message then when the user2 receives the unlock message it wait a
>>>> CDOViewAdaptersNotifiedEvent with the correct timestamp from the
>>>> InvalidationRunnable.
>>>>
>>>> What do you think about this last solution?
>>>>
>>>> Best Regards.
>>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899217 is a reply to message #899108] Tue, 31 July 2012 06:47 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Am 30.07.2012 17:03, schrieb Esteban Dugueperoux:
> Hi Eike,
>
> I have seen the new lock notification in CDO 4.1, but it doesn't solve our issue, in our use case to avoid conflict,
> we want to have a commit request followed by a unlock request be atomic and ordered
Two requests can not be atomic. They don't know each other. The first can not be undone if the second fails.

I wonder why the built-in (and default) autoReleaseLocks option of a CDOTransaction is not sufficient. To me it sounds
like a good fit for your requirements of atomic committing and unlocking.

> but currently with our use case having many users commiting their changes in a short time, a unlock request can be
> managed by the server before a commit request, especially with the invalidation step at remote users.
Yes, a second server round-trip does not sound perfect.

> Do you know a mean to have CDOTransaction.commit() call blocked until all remote users clients have their invalidation
> step done? Like that we could unlocks CDOObjects after the commit to allow remote users do changes without conflicts.
CommitTransactionNotification signals are one-way requests from the server to the clients. The server does not know
if/when the request arrives, nor if/when the needed client-side processing starts or finished. If you really want to
have this functionality, you'd have to implement your own mechanism on top of CDO. To me it doesn't look very appealing,
though, to synchronously couple the clients among each other.

There are certain hooks in the server that you could employ:
- IRepository.addHandler(WriteAccessHandler) provides access to the CommitContext before and after the commit with the
possibility to veto.
- IRepository.addCommitInfoHandler(CDOCommitInfoHandler) is a simpler interface for post-commit actions.

From a protocol perspective handleTransactionAfterCommitted() is called during
CommitTransactionIndication.indicatingCommit(). handleCommitInfo() is called at the very end of
CommitTransactionIndication.responding(), no chance anymmore to let the committing client wait.

> P.S. : I have attached a JUnit test case to show in debug the issue, putting a breakpoint in InvalidationRunnable to
> retain the main user changes integration and leaves the remote user do its changes, debug step by step the
> InvalidationRunnable previously stopped and we can see conflicts, the remote user is allowed to do changes because the
> "user1Locker.unlock();" has been executed just after the commit "user1CDOTransaction.commit();".
That's a lot of code and it seems to demo something I already know: Two separate signals can not be atomic. Is that right?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Pessimistic lock with EMF Transaction [message #899232 is a reply to message #899217] Tue, 31 July 2012 07:49 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

We manage ourself the unlock because in our application we distinguish
implicit lock (lock taken by changing a CDOObject) of explicit lock
(lock taken explicitly by the user without CDOObject change). Then we
manage locally on each client a cache of implicitly locked CDOObject and
one of explicitly locked CDOObject and on commit, we release ourself the
implicit locks but not the explicit ones.

In fact in our use case we would like to have autoReleaseLocks only for
implicit locks, then I just understand that I needs a feature request.
Do you agree this feature request for our use case?

Yes the test case show two signals.

Best Regards.

On 31/07/2012 08:47, Eike Stepper wrote:
> Am 30.07.2012 17:03, schrieb Esteban Dugueperoux:
>> Hi Eike,
>>
>> I have seen the new lock notification in CDO 4.1, but it doesn't solve
>> our issue, in our use case to avoid conflict, we want to have a commit
>> request followed by a unlock request be atomic and ordered
> Two requests can not be atomic. They don't know each other. The first
> can not be undone if the second fails.
>
> I wonder why the built-in (and default) autoReleaseLocks option of a
> CDOTransaction is not sufficient. To me it sounds like a good fit for
> your requirements of atomic committing and unlocking.
>
>> but currently with our use case having many users commiting their
>> changes in a short time, a unlock request can be managed by the server
>> before a commit request, especially with the invalidation step at
>> remote users.
> Yes, a second server round-trip does not sound perfect.
>
>> Do you know a mean to have CDOTransaction.commit() call blocked until
>> all remote users clients have their invalidation step done? Like that
>> we could unlocks CDOObjects after the commit to allow remote users do
>> changes without conflicts.
> CommitTransactionNotification signals are one-way requests from the
> server to the clients. The server does not know if/when the request
> arrives, nor if/when the needed client-side processing starts or
> finished. If you really want to have this functionality, you'd have to
> implement your own mechanism on top of CDO. To me it doesn't look very
> appealing, though, to synchronously couple the clients among each other.
>
> There are certain hooks in the server that you could employ:
> - IRepository.addHandler(WriteAccessHandler) provides access to the
> CommitContext before and after the commit with the possibility to veto.
> - IRepository.addCommitInfoHandler(CDOCommitInfoHandler) is a simpler
> interface for post-commit actions.
>
> From a protocol perspective handleTransactionAfterCommitted() is called
> during CommitTransactionIndication.indicatingCommit().
> handleCommitInfo() is called at the very end of
> CommitTransactionIndication.responding(), no chance anymmore to let the
> committing client wait.
>
>> P.S. : I have attached a JUnit test case to show in debug the issue,
>> putting a breakpoint in InvalidationRunnable to retain the main user
>> changes integration and leaves the remote user do its changes, debug
>> step by step the InvalidationRunnable previously stopped and we can
>> see conflicts, the remote user is allowed to do changes because the
>> "user1Locker.unlock();" has been executed just after the commit
>> "user1CDOTransaction.commit();".
> That's a lot of code and it seems to demo something I already know: Two
> separate signals can not be atomic. Is that right?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899272 is a reply to message #899232] Tue, 31 July 2012 09:53 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
m 31.07.2012 09:49, schrieb Esteban Dugueperoux:
> Hi Eike,
>
> We manage ourself the unlock because in our application we distinguish implicit lock (lock taken by changing a
> CDOObject) of explicit lock (lock taken explicitly by the user without CDOObject change). Then we manage locally on
> each client a cache of implicitly locked CDOObject and one of explicitly locked CDOObject and on commit, we release
> ourself the implicit locks but not the explicit ones.
This is a little confusing to me because we've been using the adjectives implicit and explicit for years but with a
totally different meaning. In CDO implicit locks are those acquired by the server on the fly during processing of a
commit. They're always released by the server at the end of the commit. In CDO explicit locks are those actively
acquired by client-side API other then CDOTransaction.commit(). Whether they get released to gether with the implicit
locks during the coming commit depends on the AutoReleaseLocks option.

Now it appears *your* implicit and explicit locks both relate to CDO's explicit locks. They just differ in who/what
explicitely acquires them, a CDOTransactionHandler i your implicit case, a user interaction in your explicit case. Is
that right?

> In fact in our use case we would like to have autoReleaseLocks only for implicit locks, then I just understand that I
> needs a feature request.
> Do you agree this feature request for our use case?
It's probably a major effort that would impact large parts of the protocl stack and I'm still having a little trouble to
see the general usefulness. I wonder how the server could distinguish your two types of locks. Would you suggest to
maintain different sets of locks per CDOView? How many sets can be considered useful and can locks transition between
the sets?

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Pessimistic lock with EMF Transaction [message #899275 is a reply to message #899272] Tue, 31 July 2012 10:11 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Yes that's right, our "implicit" locks are CDO explicit locks taken by a
listener and our "explicit" locks are CDO explicit locks taken by a
right click from a end user.

I'm not expect CDO manages our different lock types, we manages them
ourself, but instead of having a general autoReleaseLocksEnabled option,
we could inform which subset of locked CDOObjects to unlock during the
commit. In code, we could override the CDOCommitContext to specify which
CDOObject to unlock, but the CommitTransactionRequest and
CommitTransactionIndication would needs changes to support CDOIDs to
unlocks in parameter instead of a boolean autoReleaseLocks.

On 31/07/2012 11:53, Eike Stepper wrote:
> m 31.07.2012 09:49, schrieb Esteban Dugueperoux:
>> Hi Eike,
>>
>> We manage ourself the unlock because in our application we distinguish
>> implicit lock (lock taken by changing a CDOObject) of explicit lock
>> (lock taken explicitly by the user without CDOObject change). Then we
>> manage locally on each client a cache of implicitly locked CDOObject
>> and one of explicitly locked CDOObject and on commit, we release
>> ourself the implicit locks but not the explicit ones.
> This is a little confusing to me because we've been using the adjectives
> implicit and explicit for years but with a totally different meaning. In
> CDO implicit locks are those acquired by the server on the fly during
> processing of a commit. They're always released by the server at the end
> of the commit. In CDO explicit locks are those actively acquired by
> client-side API other then CDOTransaction.commit(). Whether they get
> released to gether with the implicit locks during the coming commit
> depends on the AutoReleaseLocks option.
>
> Now it appears *your* implicit and explicit locks both relate to CDO's
> explicit locks. They just differ in who/what explicitely acquires them,
> a CDOTransactionHandler i your implicit case, a user interaction in your
> explicit case. Is that right?
>
>> In fact in our use case we would like to have autoReleaseLocks only
>> for implicit locks, then I just understand that I needs a feature
>> request.
>> Do you agree this feature request for our use case?
> It's probably a major effort that would impact large parts of the
> protocl stack and I'm still having a little trouble to see the general
> usefulness. I wonder how the server could distinguish your two types of
> locks. Would you suggest to maintain different sets of locks per
> CDOView? How many sets can be considered useful and can locks transition
> between the sets?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #899356 is a reply to message #899275] Tue, 31 July 2012 14:22 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Am 31.07.2012 12:11, schrieb Esteban Dugueperoux:
> Yes that's right, our "implicit" locks are CDO explicit locks taken by a listener and our "explicit" locks are CDO
> explicit locks taken by a right click from a end user.
>
> I'm not expect CDO manages our different lock types, we manages them ourself, but instead of having a general
> autoReleaseLocksEnabled option, we could inform which subset of locked CDOObjects to unlock during the commit. In
> code, we could override the CDOCommitContext to specify which CDOObject to unlock, but the CommitTransactionRequest
> and CommitTransactionIndication would needs changes to support CDOIDs to unlocks in parameter
I think that's a reasonable enhancement request ;-)

Are you willing to provide a patch and go through the review cycles with me?

> instead of a boolean autoReleaseLocks.
Maybe we can deprecate the autoReleaseLocksEnabled option in favour of a special marker set that can be passed in
instead of a set of specific CDOIDs.

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper


>
> On 31/07/2012 11:53, Eike Stepper wrote:
>> m 31.07.2012 09:49, schrieb Esteban Dugueperoux:
>>> Hi Eike,
>>>
>>> We manage ourself the unlock because in our application we distinguish
>>> implicit lock (lock taken by changing a CDOObject) of explicit lock
>>> (lock taken explicitly by the user without CDOObject change). Then we
>>> manage locally on each client a cache of implicitly locked CDOObject
>>> and one of explicitly locked CDOObject and on commit, we release
>>> ourself the implicit locks but not the explicit ones.
>> This is a little confusing to me because we've been using the adjectives
>> implicit and explicit for years but with a totally different meaning. In
>> CDO implicit locks are those acquired by the server on the fly during
>> processing of a commit. They're always released by the server at the end
>> of the commit. In CDO explicit locks are those actively acquired by
>> client-side API other then CDOTransaction.commit(). Whether they get
>> released to gether with the implicit locks during the coming commit
>> depends on the AutoReleaseLocks option.
>>
>> Now it appears *your* implicit and explicit locks both relate to CDO's
>> explicit locks. They just differ in who/what explicitely acquires them,
>> a CDOTransactionHandler i your implicit case, a user interaction in your
>> explicit case. Is that right?
>>
>>> In fact in our use case we would like to have autoReleaseLocks only
>>> for implicit locks, then I just understand that I needs a feature
>>> request.
>>> Do you agree this feature request for our use case?
>> It's probably a major effort that would impact large parts of the
>> protocl stack and I'm still having a little trouble to see the general
>> usefulness. I wonder how the server could distinguish your two types of
>> locks. Would you suggest to maintain different sets of locks per
>> CDOView? How many sets can be considered useful and can locks transition
>> between the sets?
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #900331 is a reply to message #899356] Mon, 06 August 2012 14:06 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have studied a little more our issue, at the beginning I have tried to
write a quick and dirty code to have a list of CDOObject to unlock on
commit, like the "lock on commit for NEW CDOObjects" feature do (see
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 ). Like that the
SignalActor sent to the CDOServer is atomic to do the commit and unlock
process, but there is still the commit and lock notifications which are
not atomic and can arrives unordered on other clients. There is the same
problem for "lock on commit for NEW CDOObjects" feature
(https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 ), In comment
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045#c2 Caspar talks
about this issue which exists yet today on the master, a
LockNotificationIndication can be received before a
CommitNotificationIndication.
Then our issue is a general one for different use cases which needs to
be ensured of SignalReactor reception ordering.

I have thinked about a new signal type, a
SignalProtocol.SIGNAL_COMPOSITE (CompositeSignalActor and
CompositeSignalReactor) which could be composed of signals to manage the
atomicity and have a SignalReactorWithBroadcast abstract class
inheriting SignalReactor to register all SignalActors to broadcast to
other clients in a list and have these signals broadcasted in a
CompositeSignalActor to be atomic. Like that we could ensure the
atomicity and order of notifications in our use case and the use case of
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 , unfortunatly it
is very impacting. What do you think about that?

Best Regards.

On 31/07/2012 16:22, Eike Stepper wrote:
> Am 31.07.2012 12:11, schrieb Esteban Dugueperoux:
>> Yes that's right, our "implicit" locks are CDO explicit locks taken by
>> a listener and our "explicit" locks are CDO explicit locks taken by a
>> right click from a end user.
>>
>> I'm not expect CDO manages our different lock types, we manages them
>> ourself, but instead of having a general autoReleaseLocksEnabled
>> option, we could inform which subset of locked CDOObjects to unlock
>> during the commit. In code, we could override the CDOCommitContext to
>> specify which CDOObject to unlock, but the CommitTransactionRequest
>> and CommitTransactionIndication would needs changes to support CDOIDs
>> to unlocks in parameter
> I think that's a reasonable enhancement request ;-)
>
> Are you willing to provide a patch and go through the review cycles with
> me?
>
>> instead of a boolean autoReleaseLocks.
> Maybe we can deprecate the autoReleaseLocksEnabled option in favour of a
> special marker set that can be passed in instead of a set of specific
> CDOIDs.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>>
>> On 31/07/2012 11:53, Eike Stepper wrote:
>>> m 31.07.2012 09:49, schrieb Esteban Dugueperoux:
>>>> Hi Eike,
>>>>
>>>> We manage ourself the unlock because in our application we distinguish
>>>> implicit lock (lock taken by changing a CDOObject) of explicit lock
>>>> (lock taken explicitly by the user without CDOObject change). Then we
>>>> manage locally on each client a cache of implicitly locked CDOObject
>>>> and one of explicitly locked CDOObject and on commit, we release
>>>> ourself the implicit locks but not the explicit ones.
>>> This is a little confusing to me because we've been using the adjectives
>>> implicit and explicit for years but with a totally different meaning. In
>>> CDO implicit locks are those acquired by the server on the fly during
>>> processing of a commit. They're always released by the server at the end
>>> of the commit. In CDO explicit locks are those actively acquired by
>>> client-side API other then CDOTransaction.commit(). Whether they get
>>> released to gether with the implicit locks during the coming commit
>>> depends on the AutoReleaseLocks option.
>>>
>>> Now it appears *your* implicit and explicit locks both relate to CDO's
>>> explicit locks. They just differ in who/what explicitely acquires them,
>>> a CDOTransactionHandler i your implicit case, a user interaction in your
>>> explicit case. Is that right?
>>>
>>>> In fact in our use case we would like to have autoReleaseLocks only
>>>> for implicit locks, then I just understand that I needs a feature
>>>> request.
>>>> Do you agree this feature request for our use case?
>>> It's probably a major effort that would impact large parts of the
>>> protocl stack and I'm still having a little trouble to see the general
>>> usefulness. I wonder how the server could distinguish your two types of
>>> locks. Would you suggest to maintain different sets of locks per
>>> CDOView? How many sets can be considered useful and can locks transition
>>> between the sets?
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #900828 is a reply to message #899356] Wed, 08 August 2012 16:03 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Personaly I'm ok to provide patchs and go through review lifecyle with
you for this enhancement but before beginning I must know if you agree
with the general refactoring about composite signal because it is very
impacting CDO and can be time consuming for Obeo.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #900836 is a reply to message #900828] Wed, 08 August 2012 16:37 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Am 08.08.2012 18:03, schrieb Esteban Dugueperoux:
> Hi Eike,
>
> Personaly I'm ok to provide patchs and go through review lifecyle with you for this enhancement but before beginning I
> must know if you agree with the general refactoring about composite signal because it is very impacting CDO and can be
> time consuming for Obeo.
Thanks for your offer! I very much appreciate it. Please excuse my late answer to your other post. I'll answer there in
a minute...

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Pessimistic lock with EMF Transaction [message #900844 is a reply to message #900331] Wed, 08 August 2012 17:13 Go to previous messageGo to next message
Eike Stepper is currently offline Eike Stepper
Messages: 5545
Registered: July 2009
Senior Member
Am 06.08.2012 16:06, schrieb Esteban Dugueperoux:
> Hi Eike,
>
> I have studied a little more our issue, at the beginning I have tried to write a quick and dirty code to have a list
> of CDOObject to unlock on commit, like the "lock on commit for NEW CDOObjects" feature do (see
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 ). Like that the SignalActor sent to the CDOServer is atomic to
> do the commit and unlock process, but there is still the commit and lock notifications which are not atomic and can
> arrives unordered on other clients.
That's by design and more (synchronous) coupling between the clients of a server is not desirable in general.

> There is the same problem for "lock on commit for NEW CDOObjects" feature
> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 ), In comment
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045#c2 Caspar talks about this issue which exists yet today on the
> master, a LockNotificationIndication can be received before a CommitNotificationIndication.
> Then our issue is a general one for different use cases which needs to be ensured of SignalReactor reception ordering.
If this is really an issue then it should be solved by refactoring both CommitNotification and LockNotification signals
such that the former can reuse the logic of the latter in order to send them atomically (per client!).

Affected are the calls to sendLockNotifications() in TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit().

> I have thinked about a new signal type, a SignalProtocol.SIGNAL_COMPOSITE (CompositeSignalActor and
> CompositeSignalReactor) which could be composed of signals to manage the atomicity and have a
> SignalReactorWithBroadcast abstract class inheriting SignalReactor to register all SignalActors to broadcast to other
> clients in a list and have these signals broadcasted in a CompositeSignalActor to be atomic. Like that we could ensure
> the atomicity and order of notifications in our use case and the use case of
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 , unfortunatly it is very impacting. What do you think about that?
Coupling operations of one client (such as commit) to the execution of resulting notifications in (all) other clients is
generally not desirable. For example it's unlcear how to deal with problems in receiving clients. We don't want to
change the framework to mandate this approach.

If your specific application absolutely needs this and you accept all the drawbacks I could imagine of a comparingly
simple solution:

The Net4j signalling design does not allow for synchronous and asynchronous signal implementations in one class (we
can't make the response part optional). But the CommitNotificationRequest/Indication classes are very small and trivial.
You could implement (and contribute) an additional pair of signal classes that extend RequestWithConfirmation and
IndicationWithResponse, respectively. Then you would add a repository option for the asynchronicity of the commit
notifications and respect it in TransactionCommitContext.postCommit().

Cheers
/Eike

----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Re: [CDO] Pessimistic lock with EMF Transaction [message #901047 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #901048 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #901051 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #901054 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #901055 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #901057 is a reply to message #900844] Thu, 09 August 2012 14:14 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

Where do you see the coupling between clients of server?

If there is a design mistake it is current, because we mix commit and
lock aspects in a same request (i.e. the CommitTransactionRequest).

I don't know the initial purpose of "lock on commit of NEW objects"
feature (https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045), perhaps
Caspar De Groot could tells us what was the initial purpose of this
feature and why a CommitTransactionRequest followed by a
LockObjectsRequest was not sufficient?

Perhaps Caspar has encounters a similar issue to our issue (we execute a
CommitTransactionRequest followed by a UnlockObjectsRequest), where
other users can take the lock on concerned objects between the execution
of the LockNotificationIndication and the CommitNotificationIndication
because the network packet routing has done reception order of
LockNotificationIndication before CommitNotificationIndication.

We could imagine other use case with other request/indication
combination, for example with a call to LockObjectsRequest followed by a
CloseViewRequest to have a subset of objects to be locked on View
closing, the server could receives the second request before the first
then the LockObjectsIndication execution will failed because of the
opened View missing.

I'm agree that the needed "atomicity/signals order" is per client.

For my use case I can do a minimal refactoring to have "unlock objects
on commit" feature as do Caspar in
https://bugs.eclipse.org/bugs/show_bug.cgi?id=355045 and change the
calls to sendLockNotifications() in
TransactionCommitContext.updateInfraStructure() and
sendCommitNotification() in TransactionCommitContext.postCommit() to
ensure correct notifications arrival order on other clients.
But it is a specific coding and not very generic, every time a user want
to ensure order/atomicity between Indications reception, he must fork
the first Indication/Request code pair to manage aspect of the second
Indication/Request pair, for example for the use case of "lock on View
closing" the user must fork the CloseViewRequest/CloseViewIndication to
manage the lock aspect, as Caspar do currently for "lock of NEW object
on commit" and as we want to do for "unlock on commit".

Do you agree that the need to have SignalReactor reception order ensured
according to their counterpart SignalActor is needed on

A new type of net4j SignalActor/SignalReactor pair, which we could call
"SIGNAL_COMPOSITE_SIGNALS" could compose a sequence of SignalActor
(Request in CDO context), for exemple a CompositeActor composed of a
CommitTransactionRequest followed by a LockObjectsRequest, could ensures
the request reception order on the cdo server.

I have attached diagram explaining the composite signal solution :
- the Net4j_Composite_Signal.png explains the use of the Composite
pattern to have a sequence of Signal in a CompositeSignal sent to remote
- the Net4j_BroadcastSignalReactor.png defines a abstract
SignalReactorWithBroadcast for SignalReactor wanting to send SignalActor
to other clients
- the Composite_Signals_With_Broadcast_interaction.png interaction
diagram shows a example of use of these new types.

Best Regards.
Re: [CDO] Pessimistic lock with EMF Transaction [message #902728 is a reply to message #900836] Mon, 20 August 2012 07:34 Go to previous messageGo to next message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have created the https://bugs.eclipse.org/bugs/show_bug.cgi?id=387563
and the https://bugs.eclipse.org/bugs/show_bug.cgi?id=387564 , I begins
by the first one.

Best Regards.

On 08/08/2012 18:37, Eike Stepper wrote:
> Am 08.08.2012 18:03, schrieb Esteban Dugueperoux:
>> Hi Eike,
>>
>> Personaly I'm ok to provide patchs and go through review lifecyle with
>> you for this enhancement but before beginning I must know if you agree
>> with the general refactoring about composite signal because it is very
>> impacting CDO and can be time consuming for Obeo.
> Thanks for your offer! I very much appreciate it. Please excuse my late
> answer to your other post. I'll answer there in a minute...
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
Re: [CDO] Pessimistic lock with EMF Transaction [message #903186 is a reply to message #902728] Wed, 22 August 2012 12:55 Go to previous message
Esteban Dugueperoux is currently offline Esteban Dugueperoux
Messages: 322
Registered: July 2009
Senior Member
Hi Eike,

I have attached patchs to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=387563
> and the https://bugs.eclipse.org/bugs/show_bug.cgi?id=387564 .
It's ready for review.

Thanks.

On 20/08/2012 09:34, Esteban Dugueperoux wrote:
> Hi Eike,
>
> I have created the https://bugs.eclipse.org/bugs/show_bug.cgi?id=387563
> and the https://bugs.eclipse.org/bugs/show_bug.cgi?id=387564 , I begins
> by the first one.
>
> Best Regards.
>
> On 08/08/2012 18:37, Eike Stepper wrote:
>> Am 08.08.2012 18:03, schrieb Esteban Dugueperoux:
>>> Hi Eike,
>>>
>>> Personaly I'm ok to provide patchs and go through review lifecyle with
>>> you for this enhancement but before beginning I must know if you agree
>>> with the general refactoring about composite signal because it is very
>>> impacting CDO and can be time consuming for Obeo.
>> Thanks for your offer! I very much appreciate it. Please excuse my late
>> answer to your other post. I'll answer there in a minute...
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> http://thegordian.blogspot.com
>> http://twitter.com/eikestepper
>>
>>
>
Previous Topic:CDO/Teneo Unable to instantiate tuplizer - name collision
Next Topic:EPackage.Registry woes with different ClassLoaders
Goto Forum:
  


Current Time: Sat Oct 25 16:55:13 GMT 2014

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

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