Home » Modeling » EMF » [CDO] CDOMergingConflictResolver in action
| [CDO] CDOMergingConflictResolver in action [message #662413] |
Wed, 30 March 2011 10:50  |
Eclipse User |
|
|
|
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 11:42  |
| Eclipse User |
|
|
|
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 #662893 is a reply to message #662646] |
Fri, 01 April 2011 08:08 |
| Eclipse User |
|
|
|
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
|
|
|
Goto Forum:
Current Time: Tue Jul 22 21:05:38 EDT 2025
Powered by FUDForum. Page generated in 0.28670 seconds |
Home