Community
Participate
Working Groups
Cloned from: 316887: Databinding & CDO Notifications https://bugs.eclipse.org/bugs/show_bug.cgi?id=316887 Build Identifier: Situation at the moment: - CDO fires notifications before the conflict resolver gets called during invalidation. - Databinding relies on correct notifications fired. As an example take two transaction T1 and T2. The model contains an object O1 that has a many reference list to other objects. The list contains following elements: [a,b,c,d,e,f,g] Within transaction T1 the operation MOVE 0 -> 6 is executed. No commit at the moment. Within transaction T2 the operation REMOVE 2 is executed. No commit at the moment. Situation after the two operations: T1: [b,c,d,e,f,g,a] T2: [a,b,d,e,f,g] Then commit T1. T2 gets the invalidation. The object containing the list is marked as conflict. Next step is to create and fire the notification. The binding which has added an adapter to the object O1 to synchronize the model and the target list gets the MOVE 0->6 notification. But there is no element at index 6 what causes an IndexOutOfBounds exception. The databinding has an inconsistent state. After the notifications are distributed the conflict resolver is called. which solves the conflict. As there are many more such examples it would be better first call the conflict resolver and afterwards fire the notification. Of course a mechanism to patch the notifications should be provided. Reproducible: Always
Created attachment 178607 [details] Ported patch from head
Created attachment 178673 [details] Patch v2 - do not commit It took me several hours to make your patch binary compatible. Now a few tests are failing. Please try to find out why and fix it. Then I'll review again...
Created attachment 178674 [details] Failure List
Created attachment 179643 [details] Patch v3 updated Collected fixes from several commits. Please, review.
Created attachment 180139 [details] Patch v4 - ready to be committed This time it looks good ;-)
Committed to R3_0maintenance
Fixed
Changing version to 3.0. Let's only use major versions to indicate the development stream. If more precise baseline info is needed let's insert a time stamp in a comment.
Moving all open problem reports to 4.0
Closing.