|[CDO] Pessimistic lock with EMF Transaction [message #897856]
||Wed, 25 July 2012 09:31
| Esteban Dugueperoux
Registered: July 2009
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
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
What do you think about this last solution?
Powered by FUDForum
. Page generated in 0.01965 seconds