Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 315026

Summary: Local rollback inadvertently brings in updates from other sessions
Product: [Modeling] EMF Reporter: Caspar D. <caspar_d>
Component: cdo.coreAssignee: 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 Flags
Testcase (as a patch) none

Description Caspar D. CLA 2010-05-31 02:04:44 EDT
The current implementation of the rollback mechanism doesn't
actually replace dirty revisions with the clean ones that
were loaded (which one might expect).

What really happens is that dirty objects being rolled back,
are set to the PROXY state. Any later access to the object
will cause a call to CDORevisionManager.getRevision, which
in may go to the server for the latest revision if it is no
longer present in the cache. But this latest revision could
be different from the one originally loaded due to updates
performed in other sessions. And so the object after
rollback, isn't actually back in the state

It's obviously a bug for sessions with
passiveUpdates==false.

For passiveUpdates==true, there's room for debate regarding
whether or not the current behavior is reasonable, because
one could argue that the client is going to receive the new
value anyway in the form of a CommitNotification. But on the
other hand, even for a session using passiveUpdates, it
seems strange that rollback does not guarantee that it
*only* removes local changes -- which I think a user would
expect from a feature called "rollback", regardless of his
passiveUpdates configuration.
Comment 1 Caspar D. CLA 2010-05-31 02:09:00 EDT
Created attachment 170488 [details]
Testcase (as a patch)
Comment 2 Caspar D. CLA 2010-06-10 06:58:38 EDT
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.
Comment 3 Caspar D. CLA 2010-06-10 06:59:36 EDT
And to add further to the puzzle... which savePoint do changes 
received through passiveUpdates belong to?
Comment 4 Eike Stepper CLA 2010-06-29 04:54:30 EDT
Rebasing all outstanding 3.0 problem reports to version 3.0.1
Comment 5 Eike Stepper CLA 2010-07-07 07:10:20 EDT
Fixing wrong bug version.
Comment 6 Eike Stepper CLA 2011-06-23 04:27:00 EDT
Moving all open problem reports to 4.0
Comment 7 Eike Stepper CLA 2012-06-05 07:28:32 EDT
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!!!
Comment 8 Eike Stepper CLA 2012-08-14 22:52:37 EDT
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Comment 9 Eike Stepper CLA 2012-10-31 07:18:30 EDT
The test passes and is committed:
e255f970d7de2a032140ff808509899f0cbaaf55

This must have been fixed via some other bug.
Comment 10 Eike Stepper CLA 2013-06-27 03:32:30 EDT
Available in R20130613-1157 (4.2)