| [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514490] |
Mon, 15 February 2010 15:21  |
 Sabri Skhiri
Messages: 43
Registered: February 2010 |
Member |
|
|
Hi,
In CDO 2.0.
I listen the transactionConflictEvent between 2 concurrent transactions on the same object. I would like to define whether there is a conflict at the feature level between my local Revision Delta (local to my transaction) and the RemoteRevisionDelta (from the other concurrent transaction which has committed).
I have developed something really similar to the ThreeWayMerge conflict resolver:
I have a ChangeSubscriptionAdapter exactly as the org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver.Three WayMerge.ChangeSubscriptionAdapter which listens to my object notification events. I just add ChangeSubscriptionPolicy and attach my adapter to the EObject I am interested in.
// Add our change subscription listener
// It maintains a list of [CDOOBject, delta]
ENAChangeSubscriptionAdapter adapter = new ENAChangeSubscriptionAdapter();
// Add the subscription policy in order to let our adapter receiving events transaction2.options().addChangeSubscriptionPolicy(CDOAdapte rPolicy.ALL);
//Add a transaction listener for listening to conflict
transaction2.addListener(new ENATransactionListener(transaction2, adapter));
The problem is I would like to know if there is a conflict between local and remote RevisionDelta when the conflict event arrives.
The problem is that when I receive the CDOTransactionConflictEvent the ChangeSubscriptionAdapter has not been notified yet, the list of Delta is empty ! The adapter is notified later, after the conflict event.
Actually I need the list of remote delta in order to define whether there is a feature conflict or not, exactly as the line 220 in AbstractObjectConflictResolver.java
(getting the Remote delta list from the CDOObject on which a conflict has been detected.
@Override
protected void resolveConflict(CDOObject conflict, CDORevisionDelta revisionDelta)
{
resolveConflict(conflict, revisionDelta, adapter.getRevisionDeltas(conflict));
}
In this code the adapter is the ChangeSubscriptionAdapter, but in this case, the resolve conflict is triggered on the RUN method of the transaction Impl.
1. How can I get the remote Revision Delta from the CDOTransactionConflictEvent ?
2. Is it normal that the ChangeSubscriptionAdapter is notified after the Conflict Event ?
3. Do you think the only way is to design my client in order to register the Conflict Event (not trying to figure out whether there are conflicts), and when the ChangeSubscriptionAdapter is notified, analyzing the features delta ?
Thanx !
Sabri.
|
|
|
| Re: [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514534 is a reply to message #514490] |
Mon, 15 February 2010 12:26  |
|
Am 15.02.2010 16:21, schrieb Sabri Skhiri:
> Hi,
>
> In CDO 2.0.
> I listen the transactionConflictEvent between 2 concurrent
> transactions on the same object. I would like to define whether there
> is a conflict at the feature level between my local Revision Delta
> (local to my transaction) and the RemoteRevisionDelta (from the other
> concurrent transaction which has committed). I have developed
> something really similar to the ThreeWayMerge conflict resolver:
> I have a ChangeSubscriptionAdapter exactly as the
> org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver.Three
> WayMerge.ChangeSubscriptionAdapter which listens to my object
> notification events. I just add ChangeSubscriptionPolicy and attach my
> adapter to the EObject I am interested in.
>
> // Add our change subscription listener
> // It maintains a list of [CDOOBject, delta]
> ENAChangeSubscriptionAdapter adapter = new
> ENAChangeSubscriptionAdapter();
> // Add the subscription policy in order to let our adapter receiving
> events
> transaction2.options().addChangeSubscriptionPolicy(CDOAdapte
> rPolicy.ALL);
> //Add a transaction listener for listening to conflict
> transaction2.addListener(new ENATransactionListener(transaction2,
> adapter));
>
> The problem is I would like to know if there is a conflict between
> local and remote RevisionDelta when the conflict event arrives.
> The problem is that when I receive the CDOTransactionConflictEvent
> the ChangeSubscriptionAdapter has not been notified yet, the list of
> Delta is empty ! The adapter is notified later, after the conflict event.
>
> Actually I need the list of remote delta in order to define whether
> there is a feature conflict or not, exactly as the line 220 in
> AbstractObjectConflictResolver.java
> (getting the Remote delta list from the CDOObject on which a conflict
> has been detected.
>
> @Override
> protected void resolveConflict(CDOObject conflict, CDORevisionDelta
> revisionDelta)
> {
> resolveConflict(conflict, revisionDelta,
> adapter.getRevisionDeltas(conflict));
> }
> In this code the adapter is the ChangeSubscriptionAdapter, but in this
> case, the resolve conflict is triggered on the RUN method of the
> transaction Impl.
>
> 1. How can I get the remote Revision Delta from the
> CDOTransactionConflictEvent ?
That's not possible because this event is emitted even without change
subscription and, thus, carries less information.
> 2. Is it normal that the ChangeSubscriptionAdapter is notified after
> the Conflict Event ?
It is the expected behaviour.
> 3. Do you think the only way is to design my client in order to
> register the Conflict Event (not trying to figure out whether there
> are conflicts), and when the ChangeSubscriptionAdapter is notified,
> analyzing the features delta ?
For conflicting object you can always retrieve the local changes
directly from the transaction or its save points, at any time. Isn't
that the information you're looking for?
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] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514639 is a reply to message #514638] |
Tue, 16 February 2010 08:17 |
|
> Thanx for the clear answer.
>> For conflicting object you can always retrieve the local changes
>> directly from the transaction or its save points, at any time. Isn't
>> that the information you're looking for?
>
> Actually I am trying to evaluate if there is any way to merge the
> local changes with the remote changes, actually exactly what the
> org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver.Three WayMerge
> does. Therefore, I need:
> 1. The local changes from the transaction
I told you how to determine them.
> 2. but also be aware of the remote changes (on the server side)
An appropriate change subscription policy delivers them.
> I could compare the remote version of the conflicting object with my
> local changes, but I think it is more convenient to store the list of
> RevisionDelta from the remote object with a ChangeSubscriptionAdapter
> (exactly as the ThreeWayMerge does).
So, why don't you use ThreeWayMerge?
>
> Do you think there is a more efficient way ?
Where do you see inefficiencies?
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
|
|
|
|
Powered by
FUDForum. Page generated in 0.04035 seconds
] 
Search
Help
Register
Login
Home
