Concurrency issue while updating models
(Reported by Stuart) The scenario goes like this:
1) Mike edits the latest version of an entry. He then goes and does something else without uploading the new file. 2) Stuart edits the latest version of the same entry. He adds and uploads a new supplementary file. He saves his changes and a new version of the entry is created. 3) Mike finishes what he was doing and adds a supplementary file and uploads it. Note that he has NOT refreshed the entry so he is not viewing or editing the latest version now. 4) Mike commits his changes. 5) The latest version of the entry now contains Mike’s file, but Stuart’s has been removed. Effectively Stuart’s changes are lost (although they are accessible in the previous version).
This can be solved by an offline optimistic locking pattern. You need to check that the version of the entry being committed is the same as the latest entry. In the simplest form of this pattern you roll back the logical transaction when the versions are not equal, refresh the entry and the user starts again. Obviously a less brutal resolution is preferable to this, for example the entry is refreshed to the latest version and the user does not lose their edits. Of course that only works if the user’s edits don’t clash with any previous edits (for example uploading a file with the same name as the previous entry).