Bug 470565 - Interactive transaction conflict resolution work incorrectly with savepoints
Summary: Interactive transaction conflict resolution work incorrectly with savepoints
Status: NEW
Alias: None
Product: EMF
Classification: Modeling
Component: cdo.ui (show other bugs)
Version: 4.13   Edit
Hardware: PC All
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Project Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-06-19 05:06 EDT by Leonid Ripeynih CLA
Modified: 2020-12-11 10:43 EST (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Leonid Ripeynih CLA 2015-06-19 05:06:49 EDT
Interactive transaction conflict resolution work incorrectly with savepoints.

When transaction has more then one savepoint, only the last savepoint revision deltas gets updated, which causes "org.eclipse.emf.cdo.util.CommitConflictException: Attempt by Transaction[...] to modify historical revision" exception on commit.
Comment 1 Eike Stepper CLA 2015-06-19 05:39:49 EDT
Interactive transaction conflict resolution is still not fully and correctly  implemented. I didn't get it done before the final Mars build so it's best to wait a little longer.

And I do not plan to support interactive transaction conflict resolution in combination with savepoints. That's just too complex to handle.
Comment 2 Leonid Ripeynih CLA 2015-06-19 12:55:52 EDT
Eike, would you review/accept patches adressing this issue, or is it 'conceptually' broken, and a limitation of savepoints from a design point of view?
Comment 3 Eike Stepper CLA 2015-06-19 13:09:10 EDT
Yes, I would say it's conceptually problematic. In a way savepoints capture state of the past and it's unclear how that should change if new remote changes come in.  For example how should savepointX.rollback() behave after such internal "mangling"?
Comment 4 Leonid Ripeynih CLA 2015-06-19 15:42:50 EDT
Eike, what exactly do you mean by 'mangling'? Changing object revision delta's version in CDOCompareEditorUtil.handleMerge(..)?

You probably (and by probably I mean definitely!) have a deeper inderstandement of problem then me, but here is some thoughts...

First, how we fixed (worked around) our issue: we changed it to update the version of all revision deltas (including previous savepoints), that's far away from ideal fix, but it made commit possible. I can propose the following logic of the fix, instad of updateing revision delata versions manually, basically from UI code, it could be moved to CDOSavepoint, where it can be stored as a map (Delta -> Version). As getAllRevisionDeltas() already performs a copy of a revision deltas, it can also update the versions on revision deltas (and CDOObjects?) to commit. Since the information about that change is also stored, it could, in theory, be rolled back.
Comment 5 Eike Stepper CLA 2015-07-14 02:07:12 EDT
Moving all open bugzillas to 4.5.
Comment 6 Eike Stepper CLA 2016-07-31 00:49:45 EDT
Moving all unaddressed bugzillas to 4.6.
Comment 7 Eike Stepper CLA 2017-12-28 01:13:55 EST
Moving all open bugs to 4.7
Comment 8 Eike Stepper CLA 2019-11-08 02:10:16 EST
Moving all unresolved issues to version 4.8-
Comment 9 Eike Stepper CLA 2019-12-13 12:51:51 EST
Moving all unresolved issues to version 4.9
Comment 10 Eike Stepper CLA 2020-12-11 10:43:29 EST
Moving to 4.13.