Maintaining data concurrency in an "Ajax"

24 Mar 2006 - 8:54am
812 reads
Rahul Baji

Hi Anshuman,
I do not know if you are using SQL Server.
However I believe it is a database prb, which should be solved at the Data Tier layer rather than any tier above it.

My solution is adding a SQL timestamp column to the table.
Timestamp is not a datetime datatype, but a unique version identifier for a row.
Rather than the programmer take responsibility of ensuring the correct version, it is better to delegate it to the RDBMS
More about SQL timestamp

The way you would use it is

a)pass the timestamp along with data where selecting data
b) Whenever one updates, first check if the timestamp matches
if it does not matche, data has been updated since the select was fired
handle appropriately (Alert the user ) whatever needs to be done
depending on whether you are planning for optmistic concurrency or pessimistic concurrency
fire the update

Whenever you insert a new record, pass the timestamp so that it is available for updates if necessary

Message: 4
Date: Wed, 22 Mar 2006 15:01:37 -0800
From: Anshuman
Subject: [IxDA Discuss] Maintaining data concurrency in an "Ajax"
To: discuss at
<9c03d590603221501h5c1d2d41h4ca6a3a4f81e7045 at>
Content-Type: text/plain; charset=ISO-8859-1

I'm working on a thin client application which will be used by
multiple users concurrently and I'm having problems wrapping my head
around how we'll address overwriting of data that's being edited by
another user. Since this application will be using a lot of Ajax-type
interactions it will allow users to change individual attributes of
objects. In this case, the objects are financial data, so making sure
the user knows what the most up-to-date value (OR correct value --
these are two distinct options) is is of very high importance. A very
simple example:

Users A and B happen to be looking at the same object (a transaction)
for which they'd both like to change an attribute (transaction date).
The application is built so that the user who's looking at the
transaction details can double-click to edit the attribute and
directly save the change. If both users elect to edit at the same
time, but user A saves first how can we be sure what the system will
do with user B's save?

Or another scenario, if neither user has started editing the
attribute. If user A edits the attribute and saves the change before
user B double-clicks to change the attribute then does user B, when
they're shown value to edit, see the value they expect to be there or
do they see the value that user A had entered?

Is some kind of system polling a possible answer? One where the
system checks for value changes in the background and alerts the user?
This sounds pretty expensive in terms of bandwidth. Or should the
user have to "Refresh" in some way to get the latest and greatest

I'm assuming that we will have messaging to alert the user of any
inconsistencies, but the system still has to perform some kind of
action with the data, whether to accept it or not. I was wondering if
anyone could point me to resources for best practices, etc. in this
regard? Thanks!


Blab-away for as little as 1¢/min. Make PC-to-Phone Calls using Yahoo! Messenger with Voice.

Syndicate content Get the feed