Optimistic Locking in Sakai

1. Optimistic Locking in Sakai Lance Speelmon Charles Severance

2. The Case for Optimistic Locking • This covers the “across multiple web transaction” lock issues (i.e. where locks need to last for multiple minutes) • Three alternatives • No locking - last write wins - no checking or notification • Pessimistic locking - As user begins to edit data, a lock is taken blocking any other write access • Optimistic locking - Data is versioned - it is possible to detect if the user is trying to modify out-of-date data

3. The Case For Locking • Imagine a situation where there is a field called “total-points” regarding a student’s overall grade. • A student does two extra credit assignments, one worth 5 extra points and the other worth 10 points, and drops the first off at the instructor and the second off at the teaching assistant. • The instructor brings up the “update points” screen currently showing 60 points, but before they finish, the phone rings. • While the instructor is on the phone, the GSI brings up the same screen, sees 60 points, updates it to 70 points, and presses save. • The instructor gets off the phone, changes the 60 to 65 on their screen and presses “save” - what happens.

4. 70 60 60 65 Update Update Update Update The Scenario Instructor wants to add 5 points Screen Is there some feedback or notification that happens here? Assistant wants to add 10 points Screen What happens here - what value ends up in the database? What does the GUI look like here? Is the assistant blocked? Is the assistant notified in any way? Score: 60 Score: 70 Score: ?? Time ->

5. What happens - Update Points • In no locking, the student ends up with 65 points and no one has a clue what happened. Both the assistant and instructor can rightfully claim that they added points. Because the student is pre-med, the situation turns into a nasty lawsuit. • In pessimistic locking, the assistant cannot even bring up the screen to update points until the instructor is done. After 45 minutes, the GSI finally gives up and vows to get back to this later. • In optimistic locking, the assistant is allowed to continue, but the instructor is notified that while they were “out” the point value was changed, and the tool shows the instructor the new point value and allows the instructor to add the 5 points properly so that the student correctly gets 75 points.

6. 60 60 70 65 Update Update Update Update No Lock Instructor wants to add 5 points Screen Assistant wants to add 10 points Screen Oops - Assistant's changes lost forever Score: 60 Score: 70 Score: 65 Time ->

7. Problems with “No locking” • Some tools can tolerate “no locking” • Many assume no-locking is the nature of web • However there are many aspects of an LMS that need to be treated as “Enterprise tools”. • As the Sakai/APIs become useful outside pure LMS applications, real locking will be absolutely necessary

8. 75 65 65 60 N/A Update Retry Update Update Update Pessimistic Instructor wants to add 5 points Screen Assistant wants to add 10 points Screen N/A Retry Once it is locked, it is not available. Locked Score: 60 Score 65 Score 65 Score 65 Locked Unlocked Time ->

9. Problems with Pessimistic Locking • Can involve database resources - limits scalability • Work well (and necessary) “within” a single web transaction • Difficult to make reliable in web environment • Users can “get lock” and then navigate away - unless code is very careful, lock sits around blocking access until user logs out • If pessimistic locks time out (say 60 seconds), then code must deal with “lost lock” when trying to update information.

10. 75 Update 60 65 70 60 Version: 1 Version: 3 Version: 2 Version: 2 Update Update Update Update Score: 70 Score: 75 Score: 70 Score: 60 New information displayed to user with notification that something has changed during editing. Optimistic Instructor wants to add 5 points Screen 70 Update Session 1 / 60 1 / 65 2 / 70 2 / 75 Assistant wants to add 10 points Application decides how to handle error Screen Session and database versions now match Session 1 / 70 1 / 60 Bad-version error sent to application Session and database versions match (both are version 1) so record is updated. Time ->

11. Advantages of Optimistic Locking • Models the web and web-services environment quite naturally • “Taking a lock” is free and does not block access to resources • When an entity is finally updated, code must check for and handle “invalid data” exception while updating the object in the database. • Each tool and/or service can make independent choices as to whether or not to use optimistic locking and what to do when the framework indicates a problem.

12. Low-level DB Details • Typically, a column is added to the table which contains the “last-modified” time or perhaps an automatically incrementing integer. • When data is retrieved, this “version” is retrieved and kept. • When the application updates the data, the in-memory “version” is compared to the in-database version and the data is only updated if the version matches. • If the data has been updated, the update request fails. The application can re-retrieve the data (getting the most recent data and version) and then perform the update based on its own business rules update tPerson set eMail = new@bbn.com, dVersion = DATE_NOW where iPersonKey = 12345 and dVersion = Date(‘01/01/2004 14:45.0645’)

13. API Impacts of Optimistic Locking Option 1: Agent a = retrieveByName(“Joe”); String d = a.getDisplayName(); Retain reference to a (may not be serializable) Put up screen to modify display name a.setDisplayName(newName); // Update, ignoring version a.updateWriteThrough(); // Update checking version try { a.update(); } catch (out-of-date) { … } Option 2: Agent a = retrieveByName(“Joe”); String d = a.getDisplayName(); Version v = a.getVersion(); Retain reference to v (Version is Serializable) Put up screen to modify display name // Re-retrieve Agent a = retrieveByName(“Joe”); a.setDisplayName(newName); // Update checking version try { a.update(v); } catch (out-of-date) { … }

14. API Details // New Methods in Agent public interface Agent { Version getVersion(); // Update, using the current // version in this object void update() throws general-failure, out-of-date; // Update, using the specified // version to check against // the database version void update(Version vers) throws general-failure, out-of-date; // Update ignoring the internal // and database version void updateWriteThrough() throws general-failure; } // Note Version is Serializable

15. Pessimistic Locking Solution A possible solution for tools which need true hard locks is to develop a separate lock service. Since every first-class object has an identifier which is unique across the whole system, this Id can be used to provide a wide range of “voluntary” hard-lock features without requiring non-scalable database resource. This locking API could have a wide range of features including locks with timeouts, locks with notifications, and other features. This locking API can be specified and developed as the Application/Tool needs evolve. This API could even be evolved to provide a “notification of intent to modify” that tools could consult is the tools wanted to do so.

16. Summary Optimistic locking is a capability which is a natural fit for web applications and web-services applications There is a simple but rich model which is efficient to implement and is supported directly in Hibernate The Sakai API will have direct support for optimistic locking We have a software solution if a tool wants to keep long-term hard locks (voluntary) on any of the first-class objects in Sakai The key theme is to all the tool to make locking choices and to have API support to give the tools the capabilities which are needed