Apprenticeship in Locksmithing

Fig 1 No concurrency handling at all – Laughing Last, Laughing Longest


Fig 2 Optimistic Locking requires significant design efforts to resolve possible conflicts


Fig 3 SalesForce implementation of locking
Only prevents overwriting and not cares about your work
(see previous post for details)


Click to enlarge

Fig 4 MediaWiki optimistic locking


It allows merging and it is relatively easy to implement as it is always two text files merge task. There is no way to achieve the same results with data structures SalesForce or any business application is dealing with.


Fig 5 Pessimistic Locking is the answer


Huge advantage of this method – you do not piss of your users by dropping their changes and forcing to reload/retype, you maintain consistency of your data and most importantly you do not need to create complicated conflict resolution/merge UI-ces. The only thing you need to add is an ability to self-unlock on time out and force unlock by administrator.


Click to enlarge

Fig 6 Pessimistic Locking Quiz


- 13:00 user A loaded record and walked away
- 13:30 user A locking timeout expired
- 13:45 user B loaded record and his keyboard ‘passed away’
- 13:50 user C urgently needed same record and it was unlocked for him forcibly by admin
- 13:51 user C urgency dissolved in lunchtime and no changes were made
- it is 15:00 users A, B and C are sitting in front of their PC’s


At 15:00 all three users technically lost their right on a record. Locking component should be smart enough to let any but FIRST user to save record. All other users will get a message that:
- their lock expired
- record was changed


In this case this is clearly a user’s fault as a record was locked/changed and not saved while lock was active (saved before timeout which is set to 30 minutes in our quiz).
System allows to save data even after user’s lock was lost (expired) assuming record was not modified after it was loaded for modifications.


Click to enlarge

Fig 7 Implementation – neither proper Flowchart nor UML but a Vision I can explain to developers


Big Thanks to Greg Sherwood for sharing some insights and acting as an opponent while I was working on a concept.

  • June 23rd, 2008