Dr. Dobb's is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Channels ▼
RSS

Web Development

AJAX & Record Locking


David teaches and writes about Java and C#, and can be contacted at [email protected].


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 itself—only 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 roles—readers, 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 content—only 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.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.