Home » Modeling » EMF » [CDO] conflict merging
| |
| Re: [CDO] conflict merging [message #788813 is a reply to message #781431] |
Thu, 02 February 2012 09:00   |
 Ronald Krijgsheld
Messages: 41
Registered: November 2010 |
Member |
|
|
Hi Eike, All,
I am trying the CDOMergingConflictResolver and we sometimes get an
ArrayIndexOutOfBoundsException (see below). and I have a question.
When invalidations are received by a client how is handled that they are
processed in the right order? I have seen the
outOfSequenceInvalidations map in CDOSession. But it looks like
invalidations can come in from different threads. I don't understand how
that is order is than maintained. What I see is that multiple
InvalidationEvents are sent from different threads and I do not see how
the RemoteAggregator can merge these in order, because there is no
synchronization anywhere.
any pointers?
Thanks,
Ronald
P.S. @Eike I added you suggested fix for the stale reference, put a
breakpoint there, but never hit it yet. I it is not very reproducable.
java.lang.IndexOutOfBoundsException: Index: 6, Size: 6
at java.util.ArrayList.rangeCheck(ArrayList.java:604)
at java.util.ArrayList.remove(ArrayList.java:445)
at
org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.remove(CDOListImpl.java:180)
at
org.eclipse.emf.cdo.internal.common.revision.delta.CDORemoveFeatureDeltaImpl.apply(CDORemoveFeatureDeltaImpl.java:78)
at
org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.apply(CDOListFeatureDeltaImpl.java:405)
at
org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.apply(CDORevisionDeltaImpl.java:242)
at
com.systemizeit.pmw.cdo.PMWCDOConflictResolver.resolveConflicts(PMWCDOConflictResolver.java:106)
at
org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.handleConflicts(CDOTransactionImpl.java:724)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:514)
at
com.systemizeit.pmw.cdo.CDOConnector$PMWTransaction.doInvalidate(CDOConnector.java:194)
at
org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1241)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
at
org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:81)
at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:72)
at
org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
On 21-1-2012 8:50, Eike Stepper wrote:
> Am 18.01.2012 10:33, schrieb Ronald Krijgsheld:
>>
>> Hi All,
>>
>> We are now using the latest CDO 4.0 maintainance version. I noticed
>> that most, if not all, of the conflict resolvers are marked deprecated.
>> what is the conflict resolver that I should use?
> There is bug 341469: Make CDOMergingConflictResolver stable
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
>
> But our current tests seem to pass with it.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] conflict merging [message #794532 is a reply to message #788813] |
Thu, 09 February 2012 12:05 |
|
Am 02.02.2012 10:00, schrieb Ronald Krijgsheld:
>
> Hi Eike, All,
>
> I am trying the CDOMergingConflictResolver and we sometimes get an ArrayIndexOutOfBoundsException (see below). and I
> have a question.
There is a general bugzilla for it: https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
>
> When invalidations are received by a client how is handled that they are processed in the right order? I have seen
> the outOfSequenceInvalidations map in CDOSession. But it looks like invalidations can come in from different threads.
> I don't understand how that is order is than maintained.
With that map CDOSessionImpl.invalidate() filters out and stores out-of-sequence invalidations until a missing
invalidation arrives that closes the gap. Each thread that can close a gap executes (i.e., puts them into the
InvalidationRunnerQueue of the respective views) two or more invalidations in sequence then.
> What I see is that multiple InvalidationEvents are sent from different threads and I do not see how the
> RemoteAggregator can merge these in order, because there is no synchronization anywhere.
You mean, based on the assumption that a session delivers out-of-sequence invalidations to views? I doubt that this can
happen. What makes you think that?
>
> any pointers?
Without digging deeper, just that I don't think the root cause is wrong invalidation order.
>
> Thanks,
> Ronald
> P.S. @Eike I added you suggested fix for the stale reference, put a breakpoint there, but never hit it yet. I it is
> not very reproducable.
Sorry, what is that now? Is it related to the CDOMergingConflictResolver?
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
> java.lang.IndexOutOfBoundsException: Index: 6, Size: 6
> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
> at java.util.ArrayList.remove(ArrayList.java:445)
> at org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.remove(CDOListImpl.java:180)
> at
> org.eclipse.emf.cdo.internal.common.revision.delta.CDORemoveFeatureDeltaImpl.apply(CDORemoveFeatureDeltaImpl.java:78)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.apply(CDOListFeatureDeltaImpl.java:405)
> at org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.apply(CDORevisionDeltaImpl.java:242)
> at com.systemizeit.pmw.cdo.PMWCDOConflictResolver.resolveConflicts(PMWCDOConflictResolver.java:106)
> at org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.handleConflicts(CDOTransactionImpl.java:724)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:514)
> at com.systemizeit.pmw.cdo.CDOConnector$PMWTransaction.doInvalidate(CDOConnector.java:194)
> at org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1241)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
> at org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:81)
> at org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:72)
> at org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
>
>
>
>
> On 21-1-2012 8:50, Eike Stepper wrote:
>> Am 18.01.2012 10:33, schrieb Ronald Krijgsheld:
>>>
>>> Hi All,
>>>
>>> We are now using the latest CDO 4.0 maintainance version. I noticed
>>> that most, if not all, of the conflict resolvers are marked deprecated.
>>> what is the conflict resolver that I should use?
>> There is bug 341469: Make CDOMergingConflictResolver stable
>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
>>
>> But our current tests seem to pass with it.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> 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] conflict merging [message #795406 is a reply to message #794532] |
Fri, 10 February 2012 12:50 |
Ronald Krijgsheld
Messages: 41
Registered: November 2010 |
Member |
|
|
Hi all,
in the CDOSessionImpl in invalidateOrdered() the lastUpdateTime is set
before the invalidation event is sent or invalidations are processed by
the views, setting the lastUpdateTime frees other incoming notification
threads calling invalidate() to also call invalidateOrdered(). I am
especially worried about the order of invalidation events. As the merge
logic tries uses the remote aggregator to merge commit infos.
Another point I do not quite understand is that the aggregator is only
reset when either the transaction is committed or rolledback. But, as I
understand it more invalidations may take place within the scope of one
commit/rollback, does that mean that these delta's maintained by the
aggregator are applied more than once?
Finally, I noticed that sometimes in a sitation where there is a
conflict, i.e. both the target and source are changed, I receive for the
source only an CDORevisionKey. I would have expected here a
RevisionDelta. My guess here is that the object in my client has become
dirty after the invalidation was sent.
I try to understand this in detail because sometimes we receive
ArrayIndexOutofBounds exceptions when remove deltas are applied. But
also the commit fails on the server because of an "can only retrieve
current version for revision...", but we seem to never receive the
invalidation so that we can try to merge.
thanks
Ronald
On 9-2-2012 13:05, Eike Stepper wrote:
> Am 02.02.2012 10:00, schrieb Ronald Krijgsheld:
>>
>> Hi Eike, All,
>>
>> I am trying the CDOMergingConflictResolver and we sometimes get an
>> ArrayIndexOutOfBoundsException (see below). and I have a question.
> There is a general bugzilla for it:
> https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
>
>>
>> When invalidations are received by a client how is handled that they
>> are processed in the right order? I have seen the
>> outOfSequenceInvalidations map in CDOSession. But it looks like
>> invalidations can come in from different threads. I don't understand
>> how that is order is than maintained.
> With that map CDOSessionImpl.invalidate() filters out and stores
> out-of-sequence invalidations until a missing invalidation arrives that
> closes the gap. Each thread that can close a gap executes (i.e., puts
> them into the InvalidationRunnerQueue of the respective views) two or
> more invalidations in sequence then.
>
>> What I see is that multiple InvalidationEvents are sent from different
>> threads and I do not see how the RemoteAggregator can merge these in
>> order, because there is no synchronization anywhere.
> You mean, based on the assumption that a session delivers
> out-of-sequence invalidations to views? I doubt that this can happen.
> What makes you think that?
>
>>
>> any pointers?
> Without digging deeper, just that I don't think the root cause is wrong
> invalidation order.
>
>>
>> Thanks,
>> Ronald
>> P.S. @Eike I added you suggested fix for the stale reference, put a
>> breakpoint there, but never hit it yet. I it is not very reproducable.
> Sorry, what is that now? Is it related to the CDOMergingConflictResolver?
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
>
>> java.lang.IndexOutOfBoundsException: Index: 6, Size: 6
>> at java.util.ArrayList.rangeCheck(ArrayList.java:604)
>> at java.util.ArrayList.remove(ArrayList.java:445)
>> at
>> org.eclipse.emf.cdo.internal.common.revision.CDOListImpl.remove(CDOListImpl.java:180)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDORemoveFeatureDeltaImpl.apply(CDORemoveFeatureDeltaImpl.java:78)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDOListFeatureDeltaImpl.apply(CDOListFeatureDeltaImpl.java:405)
>>
>> at
>> org.eclipse.emf.cdo.internal.common.revision.delta.CDORevisionDeltaImpl.apply(CDORevisionDeltaImpl.java:242)
>>
>> at
>> com.systemizeit.pmw.cdo.PMWCDOConflictResolver.resolveConflicts(PMWCDOConflictResolver.java:106)
>>
>> at
>> org.eclipse.emf.internal.cdo.transaction.CDOTransactionImpl.handleConflicts(CDOTransactionImpl.java:724)
>>
>> at
>> org.eclipse.emf.internal.cdo.view.CDOViewImpl.doInvalidate(CDOViewImpl.java:514)
>>
>> at
>> com.systemizeit.pmw.cdo.CDOConnector$PMWTransaction.doInvalidate(CDOConnector.java:194)
>>
>> at
>> org.eclipse.emf.internal.cdo.view.CDOViewImpl$InvalidationRunnable.run(CDOViewImpl.java:1241)
>>
>> at
>> org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:26)
>> at org.eclipse.net4j.util.concurrent.QueueRunner.work(QueueRunner.java:1)
>> at
>> org.eclipse.net4j.util.concurrent.QueueWorker.doWork(QueueWorker.java:81)
>> at
>> org.eclipse.net4j.util.concurrent.QueueWorker.work(QueueWorker.java:72)
>> at
>> org.eclipse.net4j.util.concurrent.Worker$WorkerThread.run(Worker.java:206)
>>
>>
>>
>>
>>
>> On 21-1-2012 8:50, Eike Stepper wrote:
>>> Am 18.01.2012 10:33, schrieb Ronald Krijgsheld:
>>>>
>>>> Hi All,
>>>>
>>>> We are now using the latest CDO 4.0 maintainance version. I noticed
>>>> that most, if not all, of the conflict resolvers are marked deprecated.
>>>> what is the conflict resolver that I should use?
>>> There is bug 341469: Make CDOMergingConflictResolver stable
>>> https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
>>>
>>> But our current tests seem to pass with it.
>>>
>>> Cheers
>>> /Eike
>>>
>>> ----
>>> http://www.esc-net.de
>>> http://thegordian.blogspot.com
>>> http://twitter.com/eikestepper
>>>
>>>
>>
|
|
|
| Re: [CDO] conflict merging [message #795528 is a reply to message #795406] |
Fri, 10 February 2012 15:22 |
|
Am 10.02.2012 13:50, schrieb Ronald Krijgsheld:
>
> Hi all,
>
>
> in the CDOSessionImpl in invalidateOrdered() the lastUpdateTime is set before the invalidation event is sent or
> invalidations are processed by the views, setting the lastUpdateTime frees other incoming notification threads calling
> invalidate() to also call invalidateOrdered(). I am especially worried about the order of invalidation events. As the
> merge logic tries uses the remote aggregator to merge commit infos.
Again, can you provide evidence that the order is not correct or is your worry just a feeling because you have no other
answer?
Can you try to copy one of the test cases in ConflictResolverMergingTest andchange it so that it reproduces your situation?
> Another point I do not quite understand is that the aggregator is only reset when either the transaction is committed
> or rolledback. But, as I understand it more invalidations may take place within the scope of one commit/rollback, does
> that mean that these delta's maintained by the aggregator are applied more than once?
That sounds a bit strange and may be a bug but without a reproducible test (see above) it's hard to tell.
> Finally, I noticed that sometimes in a sitation where there is a conflict, i.e. both the target and source are
> changed, I receive for the source only an CDORevisionKey. I would have expected here a RevisionDelta. My guess here is
> that the object in my client has become dirty after the invalidation was sent.
All these situations are very easy to simulate with our test framework. And with such a test case I could probably
analyze problems very quickly and eventually fix them if they're bugs.
> I try to understand this in detail
Even just that is so much easier with a piece of test code.
> because sometimes we receive ArrayIndexOutofBounds exceptions when remove deltas are applied. But also the commit
> fails on the server because of an "can only retrieve current version for revision...", but we seem to never receive
> the invalidation so that we can try to merge.
It could be the case that, while doing the merge, the version of a merge result revision is not properly adjusted. But
without a test case it's all very hypothetical.
Cheers
/Eike
----
http://www.esc-net.de
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] conflict merging [message #795563 is a reply to message #795528] |
Fri, 10 February 2012 15:58 |
Ronald Krijgsheld
Messages: 41
Registered: November 2010 |
Member |
|
|
On 10-2-2012 16:22, Eike Stepper wrote:
> Am 10.02.2012 13:50, schrieb Ronald Krijgsheld:
>>
>> Hi all,
>>
>>
>> in the CDOSessionImpl in invalidateOrdered() the lastUpdateTime is set
>> before the invalidation event is sent or invalidations are processed
>> by the views, setting the lastUpdateTime frees other incoming
>> notification threads calling invalidate() to also call
>> invalidateOrdered(). I am especially worried about the order of
>> invalidation events. As the merge logic tries uses the remote
>> aggregator to merge commit infos.
> Again, can you provide evidence that the order is not correct or is your
> worry just a feeling because you have no other answer?
>
I put a breakpoint in the debugger on adding events to the aggregator.
And noticed that multiple threads for the same session stopped there.
> Can you try to copy one of the test cases in ConflictResolverMergingTest
> andchange it so that it reproduces your situation?
>
>> Another point I do not quite understand is that the aggregator is only
>> reset when either the transaction is committed or rolledback. But, as
>> I understand it more invalidations may take place within the scope of
>> one commit/rollback, does that mean that these delta's maintained by
>> the aggregator are applied more than once?
> That sounds a bit strange and may be a bug but without a reproducible
> test (see above) it's hard to tell.
>
I was asking for information about the design of this algorithm. One one
hand there is a stream of invalidation processed by an invalidation
runner and on the other hand there is an aggregator that stores
information per commit/rollback. Then the merger that is invoked per
invalidation asks the aggregator for its stored changes. How is
prevented that the same deltas are processed more than once.
>> Finally, I noticed that sometimes in a sitation where there is a
>> conflict, i.e. both the target and source are changed, I receive for
>> the source only an CDORevisionKey. I would have expected here a
>> RevisionDelta. My guess here is that the object in my client has
>> become dirty after the invalidation was sent.
> All these situations are very easy to simulate with our test framework.
> And with such a test case I could probably analyze problems very quickly
> and eventually fix them if they're bugs.
>
>> I try to understand this in detail
> Even just that is so much easier with a piece of test code.
>
>> because sometimes we receive ArrayIndexOutofBounds exceptions when
>> remove deltas are applied. But also the commit fails on the server
>> because of an "can only retrieve current version for revision...", but
>> we seem to never receive the invalidation so that we can try to merge.
> It could be the case that, while doing the merge, the version of a merge
> result revision is not properly adjusted. But without a test case it's
> all very hypothetical.
>
> Cheers
> /Eike
>
> ----
> http://www.esc-net.de
> http://thegordian.blogspot.com
> http://twitter.com/eikestepper
>
>
|
|
|
| Re: [CDO] conflict merging [message #795618 is a reply to message #795563] |
Fri, 10 February 2012 17:34 |
|
Am 10.02.2012 16:58, schrieb Ronald Krijgsheld:
> On 10-2-2012 16:22, Eike Stepper wrote:
>> Am 10.02.2012 13:50, schrieb Ronald Krijgsheld:
>>>
>>> Hi all,
>>>
>>>
>>> in the CDOSessionImpl in invalidateOrdered() the lastUpdateTime is set
>>> before the invalidation event is sent or invalidations are processed
>>> by the views, setting the lastUpdateTime frees other incoming
>>> notification threads calling invalidate() to also call
>>> invalidateOrdered(). I am especially worried about the order of
>>> invalidation events. As the merge logic tries uses the remote
>>> aggregator to merge commit infos.
>> Again, can you provide evidence that the order is not correct or is your
>> worry just a feeling because you have no other answer?
>>
>
> I put a breakpoint in the debugger on adding events to the aggregator. And noticed that multiple threads for the same
> session stopped there.
This bugzilla should have fixed that:
328352: CommitNotifications overtaking each other
https://bugs.eclipse.org/bugs/show_bug.cgi?id=328352
It could be possible that it's not correctly fixed and there's still a way for invalidations to arrive out-of-sequence
in the per-view queues.
>
>> Can you try to copy one of the test cases in ConflictResolverMergingTest
>> andchange it so that it reproduces your situation?
>>
>>> Another point I do not quite understand is that the aggregator is only
>>> reset when either the transaction is committed or rolledback. But, as
>>> I understand it more invalidations may take place within the scope of
>>> one commit/rollback, does that mean that these delta's maintained by
>>> the aggregator are applied more than once?
>> That sounds a bit strange and may be a bug but without a reproducible
>> test (see above) it's hard to tell.
>>
>
> I was asking for information about the design of this algorithm. One one hand there is a stream of invalidation
> processed by an invalidation runner and on the other hand there is an aggregator that stores information per
> commit/rollback. Then the merger that is invoked per invalidation asks the aggregator for its stored changes. How is
> prevented that the same deltas are processed more than once.
I can't remember these details from my head and I don't have the time right now to fully dig into it. As I said, it's
well possible that the CDOMergingConflictResolver still has bugs, that's why this bugzilla is still open:
341469: Make CDOMergingConflictResolver stable
https://bugs.eclipse.org/bugs/show_bug.cgi?id=341469
Cheers
/Eike
----
http://www.esc-net.de
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] conflict merging [message #797216 is a reply to message #795563] |
Mon, 13 February 2012 07:31 |
|
Hi Ronald,
I've been digging again and I think there's a short period in CDOSessionImpl where two invalidations can still overtake
each other on their way to the views. After hours of trying different solutions I still haven't all tests passing. Will
take a while...
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 10.02.2012 16:58, schrieb Ronald Krijgsheld:
> On 10-2-2012 16:22, Eike Stepper wrote:
>> Am 10.02.2012 13:50, schrieb Ronald Krijgsheld:
>>>
>>> Hi all,
>>>
>>>
>>> in the CDOSessionImpl in invalidateOrdered() the lastUpdateTime is set
>>> before the invalidation event is sent or invalidations are processed
>>> by the views, setting the lastUpdateTime frees other incoming
>>> notification threads calling invalidate() to also call
>>> invalidateOrdered(). I am especially worried about the order of
>>> invalidation events. As the merge logic tries uses the remote
>>> aggregator to merge commit infos.
>> Again, can you provide evidence that the order is not correct or is your
>> worry just a feeling because you have no other answer?
>>
>
> I put a breakpoint in the debugger on adding events to the aggregator. And noticed that multiple threads for the same
> session stopped there.
>
>> Can you try to copy one of the test cases in ConflictResolverMergingTest
>> andchange it so that it reproduces your situation?
>>
>>> Another point I do not quite understand is that the aggregator is only
>>> reset when either the transaction is committed or rolledback. But, as
>>> I understand it more invalidations may take place within the scope of
>>> one commit/rollback, does that mean that these delta's maintained by
>>> the aggregator are applied more than once?
>> That sounds a bit strange and may be a bug but without a reproducible
>> test (see above) it's hard to tell.
>>
>
> I was asking for information about the design of this algorithm. One one hand there is a stream of invalidation
> processed by an invalidation runner and on the other hand there is an aggregator that stores information per
> commit/rollback. Then the merger that is invoked per invalidation asks the aggregator for its stored changes. How is
> prevented that the same deltas are processed more than once.
>
>>> Finally, I noticed that sometimes in a sitation where there is a
>>> conflict, i.e. both the target and source are changed, I receive for
>>> the source only an CDORevisionKey. I would have expected here a
>>> RevisionDelta. My guess here is that the object in my client has
>>> become dirty after the invalidation was sent.
>> All these situations are very easy to simulate with our test framework.
>> And with such a test case I could probably analyze problems very quickly
>> and eventually fix them if they're bugs.
>>
>>> I try to understand this in detail
>> Even just that is so much easier with a piece of test code.
>>
>>> because sometimes we receive ArrayIndexOutofBounds exceptions when
>>> remove deltas are applied. But also the commit fails on the server
>>> because of an "can only retrieve current version for revision...", but
>>> we seem to never receive the invalidation so that we can try to merge.
>> It could be the case that, while doing the merge, the version of a merge
>> result revision is not properly adjusted. But without a test case it's
>> all very hypothetical.
>>
>> Cheers
>> /Eike
>>
>> ----
>> http://www.esc-net.de
>> 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] conflict merging [message #900679 is a reply to message #900610] |
Wed, 08 August 2012 07:13 |
|
Am 07.08.2012 20:53, schrieb Roger Whte:
> I've begun using CDO somewhat recently and I've been asked to resolve some multiuser bugs in code that depends on the
> CDOMergingConflictResolver. Much like Ronald, I've looked through the documentation for every conflict resolver and
> discovered every single one except AbstractObjectConflictResolver.ThreeWayMerge is deprecated. Does this mean I
> should change our code to remove all use of CDOMergingConflictResolver and switch to
> AbstractObjectConflictResolver.ThreeWayMerge? I've read through the ThreeWayMerge conflict resolver and in general,
> the code seems reasonable and might work for our use case. However it makes me nervous when I perform a Google search
> for this class and it is NEVER mentioned except in the CDO API docs. The Google results finds only three links. So I
> question whether anyone has ever used this class with success. Our current code fails on certain multiuser scenarios
> where conflicts must be merged. The code fails on some occasions with index out of bounds exceptions and in the case
> of a deleting an Entity the application hangs and the UI will never become responsive again.
>
> So what's the bottom line *today*. What conflict resolver (if any) can be used with success *now*, not sometime in
> the future.
I hate to say that not much has changed regarding the state of the conflict resolvers ;-(
Perhaps you want to help us and analyze the problems you're having.
Cheers
/Eike
----
http://www.esc-net.de
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] conflict merging [message #901149 is a reply to message #901117] |
Fri, 10 August 2012 05:56 |
|
Hi Roger,
That's great news ;-)
Today I'm on travel but I can try to write up some SPI docs for merging and conflict resolving over the weekend. If that
turns out too ambitious I can also offer to have a Skype/Teamviewer session with you next wek to explain the important
facts about CDORevisions, CDORevisionDeltas, CDOBranches, CDOBranchPoints and the design of the default CDOMerger
implementations. If you already have concrete questions don't hesitate to ask them here.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
Am 09.08.2012 23:08, schrieb Roger White:
> Hi Eike,
>
> Thanks for the quick reply. I've talked to my management and they are willing for me to contribute some time and
> effort to improving the CDO merging conflict resolvers, and probably contribute code if needed. However I'm new to
> CDO, so I might be of less help than some others. I'm reading what web resources and CDO code that seems useful, but
> of course it takes time to get up to speed on a large complex code-base. I would be very happy if you could suggest
> any particularly helpful books or articles that could accelerate my learning of CDO.
>
> Many thanks,
> Roger
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Sat Apr 20 03:52:27 GMT 2024
Powered by FUDForum. Page generated in 0.04651 seconds |
] 
Search
Help
Register
Login
Home
