Consider this scenario: Client A calls up Record100 of a multiuser web application and begins editing it. Client B calls up the same Record100 moments later, and while Client B is modifying it, Client A saves changes to Record100. Now Client B is unwittingly modifying a record that is no longer current, and when Client B saves the record, the changes made by Client A are lost. This is an untenable situation where the last one to the finish line wins, and all others are obliterated. It would be best to find a way to inform Client B that editing is not possible as long as Client A is editing. And when Client A is done editing, it would be best to refresh Client B's view of Record100 so it includes the changes made by Client A.
Relying on database locking in web-based applications is less than optimal because the lock exists in the database. This is significant because it exists only for the duration of the transaction itselfonly when the server is working with the database, not when the client is working with the UI. Because the lock exists in the database, clients have no knowledge of locked records. If the server could push information about locked records to clients, this situation would be remedied, but there really is no good web-oriented push technology.
In this article, I describe a client-based technique for record locking for multiuser data-driven web applications that does not take place in the database. Instead, it is enforced by modifying the UI to lockout users when more than one user accesses the same record. I show how we do this for our web applications, which for the most part are data-mining applications backed by a leading relational database and developed for a closed intranet committed to IE browsers. These applications have three user rolesreaders, editors, and administrators. Typically, we control application access by user role, so when users log into an application, their navigational path through the web app is determined by the role that user is assigned. This means that users with the role of reader are never given a link to editable contentonly to read-only content.
In fact, all users originally see only the reader view no matter what their role-based privileges allow. Because the reader view does not present editable content, qualified editors (which include administrators) must request the editable view to modify data. This request involves clicking on an Edit button in the UI of the reader view. (If a user's role is below that of editor, the Edit button is permanently removed from the UI.) This edit-request step lets us be certain of always fetching the most current data when an editing session begins. Whenever users are editing, they are modifying existing records, for which there is a unique record ID in the database. If an editor clicks on the Edit button, the browser requests the editable view of the current page. That trip to the server places an entry in a map denoting what record is locked, and by which editor. The user then receives the editable view of the record.
To prevent two editors from editing the same page, view-only pages (with the Edit button on them) contain an AJAX call that runs initially in window.onload, and thereafter in a window.setTimeout loop. This AJAX call bounces the record ID of the currently viewed record off the server, asking if someone holds the lock for that record ID. If the server responds that it is locked, the Edit button is removed from the UI and an alert is popped up informing the current user that the record is locked, and who locked it. Because the AJAX call runs in the window.setTimeout loop, such a response to another user's locking of the record could happen a while after the page is loaded.
The window.setTimeout loop on the locked-out user's page continues to run, requesting the lock status from the server, and when the lock owner saves the record or leaves the editable page, the AJAX call detects this and restores the Edit button. Clicking on the Edit button to go into edit mode then causes another round trip to the server to get the latest version of the record to place on the page in edit mode, as well as establish with the server that there is a new lock owner for that record.