Home » Modeling » EMF » [CDO] CDOMergingConflictResolver in action
| [CDO] CDOMergingConflictResolver in action [message #662413] |
Wed, 30 March 2011 14:50  |
 Sebastian Paul
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  |
|
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?
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
| | |
Goto Forum:
Current Time: Tue Apr 16 17:00:45 GMT 2024
Powered by FUDForum. Page generated in 0.57971 seconds |
] 
Search
Help
Register
Login
Home
