Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Modeling » EMF » [CDO] CDOMergingConflictResolver in action
[CDO] CDOMergingConflictResolver in action [message #662413] Wed, 30 March 2011 14:50 Go to next message
Sebastian Paul is currently offline Sebastian PaulFriend
Messages: 106
Registered: July 2009
Senior Member
Hi,
after switching from CDO 3.0 to 4.0, I had to exchange the conflict
resolver MergeLocalChangesPerFeature by CDOMergingConflictResolver.
Now I'm getting conflicts when the same feature has been changed
concurrently. Previously, this has been resolved by overwriting the
first change.

LOGGER.debug("[1] adding resource with content");
final CDOResource resource1 =
transaction1.getOrCreateResource(CDO_RESOURCE_PATH);
addContentToResource(resource1);
transaction1.commit();

LOGGER.debug("[1] adding conflict resolver");
transaction1.options().addConflictResolver(new
CDOMergingConflictResolver());
LOGGER.debug("[2] adding conflict resolver");
transaction2.options().addConflictResolver(new
CDOMergingConflictResolver());

// modify element

LOGGER.debug("[1] modifying element");
modifyElement(transaction1.getResource(CDO_RESOURCE_PATH),
CMTPackage.Literals.NAMED_ELEMENT__NAME, "name1");
modifyElement(transaction1.getResource(CDO_RESOURCE_PATH),
CMTPackage.Literals.NAMED_ELEMENT__DESCRIPTION, "description1");

LOGGER.debug("[2] modifying element");
modifyElement(transaction2.getResource(CDO_RESOURCE_PATH),
CMTPackage.Literals.NAMED_ELEMENT__NAME, "name2");
modifyElement(transaction1.getResource(CDO_RESOURCE_PATH),
CMTPackage.Literals.PROJECT__DOCUMENT_STORE_ID, "store2");

LOGGER.debug("[1] committing transaction");
transaction1.commit();

LOGGER.debug("[2] committing transaction");
transaction2.commit();

The second commit throws
[ERROR] Merger could not resolve all conflicts:
{OID3=ChangedInSourceAndTarget[target=CDORevisionDelta[Project@OID3:0v1
--> [CDOFeatureDelta[name, SET, value=name2, oldValue=busbar HL]]],
source=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET,
value=name1, oldValue=busbar HL]]]]}
org.eclipse.emf.spi.cdo.DefaultCDOMerger$ConflictException: Merger could
not resolve all conflicts:
{OID3=ChangedInSourceAndTarget[target=CDORevisionDelta[Project@OID3:0v1
--> [CDOFeatureDelta[name, SET, value=name2, oldValue=busbar HL]]],
source=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET,
value=name1, oldValue=busbar HL]]]]}
at
org.eclipse.emf.spi.cdo.DefaultCDOMerger.merge(DefaultCDOMer ger.java:108)
at
org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.resolveCo nflicts(CDOMergingConflictResolver.java:60)
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. handleConflicts(CDOTransactionImpl.java:708)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(C DOViewImpl.java:420)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRu nnable.run(CDOViewImpl.java:1135)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:26)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:1)
at
org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWo rker.java:81)
at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWork er.java:72)
at
org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Wo rker.java:206)

The new resolver is still marked as 'under construction', but
https://bugs.eclipse.org/bugs/show_bug.cgi?id=319090 is resolved as
fixed. So how is the actual status?
Is the above behavior by design? Currently I am using the default
constructor CDOMergingConflictResolver(), which uses
DefaultCDOMerger.PerFeature.ManyValued. Do I need a different merger? Or
implement my own?

--
Best regards,
Sebastian Paul
Re: [CDO] CDOMergingConflictResolver in action [message #662431 is a reply to message #662413] Wed, 30 March 2011 15:42 Go to previous messageGo to next message
Eike Stepper is currently offline Eike StepperFriend
Messages: 6446
Registered: July 2009
Senior Member
Hi Sebastian,

The CDOMergingConflictResolver is still under development. The JavaDoc says:

@deprecated This conflict resolver is still under development. It's not safe to use it.

It was supposed to be operational already, when we found out that there's a severe issue with applying the produced deltas to the local transaction. That's why MergeLocalChangesPerFeature is also already marked deprecated. But you should still be able to use MergeLocalChangesPerFeature. I'm currently on vacation and can not find the bug that you would cc yourself on in order to get notified about status changes. You could file a new one to remind me.

Cheers
/Eike

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



Am 30.03.2011 07:50, schrieb Sebastian Paul:
> Hi,
> after switching from CDO 3.0 to 4.0, I had to exchange the conflict resolver MergeLocalChangesPerFeature by CDOMergingConflictResolver.
> Now I'm getting conflicts when the same feature has been changed concurrently. Previously, this has been resolved by overwriting the first change.
>
> LOGGER.debug("[1] adding resource with content");
> final CDOResource resource1 = transaction1.getOrCreateResource(CDO_RESOURCE_PATH);
> addContentToResource(resource1);
> transaction1.commit();
>
> LOGGER.debug("[1] adding conflict resolver");
> transaction1.options().addConflictResolver(new CDOMergingConflictResolver());
> LOGGER.debug("[2] adding conflict resolver");
> transaction2.options().addConflictResolver(new CDOMergingConflictResolver());
>
> // modify element
>
> LOGGER.debug("[1] modifying element");
> modifyElement(transaction1.getResource(CDO_RESOURCE_PATH), CMTPackage.Literals.NAMED_ELEMENT__NAME, "name1");
> modifyElement(transaction1.getResource(CDO_RESOURCE_PATH), CMTPackage.Literals.NAMED_ELEMENT__DESCRIPTION, "description1");
>
> LOGGER.debug("[2] modifying element");
> modifyElement(transaction2.getResource(CDO_RESOURCE_PATH), CMTPackage.Literals.NAMED_ELEMENT__NAME, "name2");
> modifyElement(transaction1.getResource(CDO_RESOURCE_PATH), CMTPackage.Literals.PROJECT__DOCUMENT_STORE_ID, "store2");
>
> LOGGER.debug("[1] committing transaction");
> transaction1.commit();
>
> LOGGER.debug("[2] committing transaction");
> transaction2.commit();
>
> The second commit throws
> [ERROR] Merger could not resolve all conflicts: {OID3=ChangedInSourceAndTarget[target=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET, value=name2, oldValue=busbar HL]]], source=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET, value=name1, oldValue=busbar HL]]]]}
> org.eclipse.emf.spi.cdo.DefaultCDOMerger$ConflictException: Merger could not resolve all conflicts: {OID3=ChangedInSourceAndTarget[target=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET, value=name2, oldValue=busbar HL]]], source=CDORevisionDelta[Project@OID3:0v1 --> [CDOFeatureDelta[name, SET, value=name1, oldValue=busbar HL]]]]}
> at org.eclipse.emf.spi.cdo.DefaultCDOMerger.merge(DefaultCDOMer ger.java:108)
> at org.eclipse.emf.spi.cdo.CDOMergingConflictResolver.resolveCo nflicts(CDOMergingConflictResolver.java:60)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. handleConflicts(CDOTransactionImpl.java:708)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(C DOViewImpl.java:420)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRu nnable.run(CDOViewImpl.java:1135)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:26)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunn er.java:1)
> at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWo rker.java:81)
> at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWork er.java:72)
> at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Wo rker.java:206)
>
> The new resolver is still marked as 'under construction', but https://bugs.eclipse.org/bugs/show_bug.cgi?id=319090 is resolved as fixed. So how is the actual status?
> Is the above behavior by design? Currently I am using the default constructor CDOMergingConflictResolver(), which uses DefaultCDOMerger.PerFeature.ManyValued. Do I need a different merger? Or implement my own?
>


Re: [CDO] CDOMergingConflictResolver in action [message #662646 is a reply to message #662431] Thu, 31 March 2011 12:24 Go to previous messageGo to next message
Sebastian Paul is currently offline Sebastian PaulFriend
Messages: 106
Registered: July 2009
Senior Member
Comments below...

Am 2011-03-30 17:42, schrieb Eike Stepper:
> The CDOMergingConflictResolver is still under development. The JavaDoc
> says:
> @deprecated This conflict resolver is still under development. It's not
> safe to use it.
> It was supposed to be operational already, when we found out that
> there's a severe issue with applying the produced deltas to the local
> transaction. That's why MergeLocalChangesPerFeature is also already
> marked deprecated. But you should still be able to use
> MergeLocalChangesPerFeature.
The behaviour of the old MergeLocalChangesPerFeature must have changed,
as my tests failed after switching to the new version. Most conflicts
which have been previously resolved are not resolved any more. That was
the reason for moving to CDOMergingConflictResolver.

> I'm currently on vacation and can not find
> the bug that you would cc yourself on in order to get notified about
> status changes. You could file a new one to remind me.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469

--
Best regards,
Sebastian Paul
Re: [CDO] CDOMergingConflictResolver in action [message #662893 is a reply to message #662646] Fri, 01 April 2011 12:08 Go to previous message
Sebastian Paul is currently offline Sebastian PaulFriend
Messages: 106
Registered: July 2009
Senior Member
Am 2011-03-31 14:24, schrieb Sebastian Paul:
> The behaviour of the old MergeLocalChangesPerFeature must have changed,
> as my tests failed after switching to the new version. Most conflicts
> which have been previously resolved are not resolved any more. That was
> the reason for moving to CDOMergingConflictResolver.

I am always getting this error:

[ERROR] Object has feature-level conflicts
org.eclipse.emf.cdo.common.util.CDOException: Object has feature-level conflicts
at org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver$Merge LocalChangesPerFeature.resolveConflict(AbstractObjectConflic tResolver.java:361)
at org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver$Three WayMerge.resolveConflict(AbstractObjectConflictResolver.java :279)
at org.eclipse.emf.spi.cdo.AbstractObjectConflictResolver.resol veConflicts(AbstractObjectConflictResolver.java:102)
at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl. handleConflicts(CDOTransactionImpl.java:704)
at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(C DOViewImpl.java:420)

--
Best regards,
Sebastian Paul
Previous Topic:Loading XML with a schema that extends via substitutionGroup
Next Topic:Generated tests from EMF
Goto Forum:
  


Current Time: Tue Oct 22 11:26:06 GMT 2019

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

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

Back to the top