| Summary: | Local rollback inadvertently brings in updates from other sessions | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Modeling] EMF | Reporter: | Caspar D. <caspar_d> | ||||
| Component: | cdo.core | Assignee: | Eike Stepper <stepper> | ||||
| Status: | CLOSED FIXED | QA Contact: | Eike Stepper <stepper> | ||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | saulius.tvarijonas | ||||
| Version: | 4.2 | ||||||
| Target Milestone: | --- | ||||||
| Hardware: | All | ||||||
| OS: | All | ||||||
| Whiteboard: | |||||||
| Attachments: |
|
||||||
|
Description
Caspar D.
Created attachment 170488 [details]
Testcase (as a patch)
I wonder, what are our desired/intended semantics anyway when a tx is rolled back after receiving passiveUpdates? Should the rollback only undo changes that were made in the local session, and not undo changes that were received as passive updates? That would kinda make sense, but techically this might be hard to do. The other option is to just undo everything.. but how would the user be aware that he is discarding MORE than his own changes, i.e. he's also discarding changes that he received from another session? Hmmm.... a puzzle. And to add further to the puzzle... which savePoint do changes received through passiveUpdates belong to? Rebasing all outstanding 3.0 problem reports to version 3.0.1 Fixing wrong bug version. Moving all open problem reports to 4.0 Moving all open bug reports to 4.1 because the release is very near and it's hghly unlikely that there will be spare time to address 4.0 problems. Please make sure that your patches can be applied against the master branch and that your problem is not already fixed there!!! Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master. The test passes and is committed: e255f970d7de2a032140ff808509899f0cbaaf55 This must have been fixed via some other bug. Available in R20130613-1157 (4.2) |