Maintaining data concurrency in an "Ajax" environment

22 Mar 2006 - 6:01pm
8 years ago
6 replies
915 reads
Anshuman
2006

Hello,
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
information?

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!

Anshuman

Comments

22 Mar 2006 - 6:17pm
Andrew Hedges
2006

Anshuman,

Yes, you could have the system poll the server every X seconds to
retrieve the latest values for the properties in question, but even
then there will be a potential X second lag during which a user may
change the values unbeknownst to another user. It would be very
difficult to ensure the integrity of the data in such a system.

I'm assuming from your post that it is a design requirement to allow
multiple users access to particular property values simultaneously.
If that's not a strict requirement, you could have some kind of
"check out/check in" system where a user could essentially lock out
other users for some period of time.

HTH,

-Andrew
-----
andrew at clearwired.com / http://clearwired.com

On Mar 22, 2006, at 3/22/2006 4:01 PM, Anshuman wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> Hello,
> 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
> information?
>
> 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!
>
> Anshuman

22 Mar 2006 - 7:11pm
Jeff Howard
2004

Anshuman,

In your example, the system could have a "last edited" attribute for the data in question. In
addition, each user could be assigned a "began editing" attribute. On save, the page first
checks the server to confirm that the attribute's "last edited" date is still before the users
"began editing" date. If not, it suspends the save, displays a message alerting the user to the
change, shows the new value, and shows them who changed it. Then it allows them to
override and notify the previous editor.

Depending on the length of time an editing operation is anticipated to take (and therefore
how likely an overlap is to exist) you might consider periodic polling during the longer edits
(maybe every minute or so), to see if anyone else has begun editing.

Another possibility [on preview what Andrew mentions] is to prevent the scenario in the first
place by enforcing a check-in/check-out framework in which one user cannot begin editing
an attribute that is currently being edited. This probably requires an onscreen explanation of
why the attribute is locked.

// jeff

Jeff Howard
Interaction Designer
Smart Design

22 Mar 2006 - 9:50pm
Bronwyn Boltwood
2004

On 3/22/06, Anshuman <sidesreversedis at gmail.com> wrote:
> [Please voluntarily trim replies to include only relevant quoted material.]
>
> 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.

You might want to look at how PmWiki handles this kind of situation.
Back when I first started using this wiki engine in 2003, they used
page locking. Page locking was not so good a solution, as explained
in http://pmwiki.org/wiki/PmWiki/PageLocking. PmWiki now has
simultaneous edits (http://pmwiki.org/wiki/PmWiki/SimultaneousEdits).
You can count on the developer, Pm, having excellent reasons for
having done it the way that he has. He is willing to take the time to
solve tough problems the right way, and that one took him roughly a
year.

Bronwyn

23 Mar 2006 - 10:31am
Becubed
2004

> 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.

I've worked on numerous products with this same requirement. IMHO,
this is a prime example of a situation in which the best solution is
the simplest solution: when someone begins an edit, lock the object
to prevent anyone else initiating a simultaneous edit. Any of the
more clever approaches seem to ratchet up the complexity a fair bit
and, in fact, create *more* scenarios that your design needs to
address — and that users will encounter along the way.

You'll need to provide a feedback loop for the person attempting the
simultaneous edit. What seems to work nicely is a brief message that
communicates the idea:

"You cannot edit [Object] because someone else is doing so already."

If you're powering this through Ajax, you could pop that message
right next to the object itself. When someone clicks to initiate an
edit, immediately query the server to discover if the object is
checked out by anyone else. This eliminates the need for periodic
"polling", which eats bandwidth and still doesn't guarantee that
information will be up to date.

In my experience (including programming environments built around the
idea of check in/out), people have trouble wrapping their heads
around "merging" versions of objects -- similar to a recent thread in
which we lamented how people stumble over boolean logic in search
queries. It *seems* so straightforward! But it's not. <sigh>

--
Robert Barlow-Busch
Practice Director, Interaction Design
Quarry Integrated Communications Inc.

23 Mar 2006 - 11:31am
jrrogan
2005

I've got to agree with Robert for complex applications.

I've worked on several thin client applications, emulating thick client
functionality, (Ajax in Pre-Ajax world), and although it may be technically
feasible to merge data, this merge becomes increasingly problematic with the
complexity of the data being merged.

In a complex problem space, it is very difficult to merge together edits and
maintain integrity of the various user intentions.

The case is made to lock down edits when the value is higher to limit access
and stop errors.

23 Mar 2006 - 2:07pm
Andrew Hedges
2006

On the PmWiki PageLocking page, the developer explains why locking a
page is problematic in a stateless environment such as the web. Good
points, but now that we have asynchronous HTTP requests at our
disposal, less so.

Rather than setting a timeout for a page lock of, for example, 30
minutes, an AJAX-y routine could tell the server every minute or so
that the page is still being edited. So, if the user abandons the
edit by leaving the page in any way (closing the browser, using the
back button, etc.), the page is then unlocked after only a minute.

-Andrew
-----
andrew at clearwired.com / http://clearwired.com/

On Mar 22, 2006, at 3/22/2006 7:50 PM, Bronwyn Boltwood wrote:

> [Please voluntarily trim replies to include only relevant quoted
> material.]
>
> On 3/22/06, Anshuman <sidesreversedis at gmail.com> wrote:
>> [Please voluntarily trim replies to include only relevant quoted
>> material.]
>>
>> 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.
>
> You might want to look at how PmWiki handles this kind of situation.
> Back when I first started using this wiki engine in 2003, they used
> page locking. Page locking was not so good a solution, as explained
> in http://pmwiki.org/wiki/PmWiki/PageLocking. PmWiki now has
> simultaneous edits (http://pmwiki.org/wiki/PmWiki/SimultaneousEdits).
> You can count on the developer, Pm, having excellent reasons for
> having done it the way that he has. He is willing to take the time to
> solve tough problems the right way, and that one took him roughly a
> year.
>
> Bronwyn

Syndicate content Get the feed