Community
Participate
Working Groups
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.
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)
