Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter(Comparing local RevisionDelta and RemoteRevisionDelta)
[CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514490] Mon, 15 February 2010 15:21 Go to next message
Sabri Skhiri is currently offline Sabri SkhiriFriend
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 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6690
Registered: July 2009
Senior Member
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


Re: [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514638 is a reply to message #514534] Tue, 16 February 2010 08:14 Go to previous messageGo to next message
Sabri Skhiri is currently offline Sabri SkhiriFriend
Messages: 43
Registered: February 2010
Member
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
2. but also be aware of the remote changes (on the server side)
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).

Do you think there is a more efficient way ?

Cheers,
Sabri.
Re: [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514639 is a reply to message #514638] Tue, 16 February 2010 08:17 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6690
Registered: July 2009
Senior Member
> 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


Re: [CDO] CDOTransactionConflictEvent Vs ChangeSubscriptionAdapter [message #514643 is a reply to message #514639] Tue, 16 February 2010 08:31 Go to previous message
Sabri Skhiri is currently offline Sabri SkhiriFriend
Messages: 43
Registered: February 2010
Member
OK great ! I was just looking for any other ways to get it.
Thanx for the support.

Sabri.
Previous Topic:[CDO] instance objects and java Serializable
Next Topic:[EMF Databinding] Need an ObservableMapContentProvider?
Goto Forum:
  


Current Time: Fri Sep 20 12:47:09 GMT 2024

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

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

Back to the top