Versions Compared

Old Version 18

changes.mady.by.user David E Tanner

Saved on

compared with

New Version 19

changes.mady.by.user Stephen Turner

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Panel

About this Page

indent
1
1
This document outlines the issues involved in dealing with concurrent database updates in our web apps - the situation where more than one user tries to update the same piece of data at the same time. See "Chosen Solution" below for... our chosen solution.

To

set

the

scene,

here's

a

typical

situation

in

our

web

applications:

*

  • Dave
  • pulls
  • up
  • data
  • in
  • his
  • browser.
  • Goes
  • to
  • lunch.
*
  • Shahla
  • pulls
  • up
  • same
  • data,
  • makes
  • a
  • change
  • and
  • saves.
  • Changes
  • are
  • committed
  • to
  • the
  • DB.
*
  • Dave
  • comes
  • back
  • from
  • lunch,
  • changes
  • the
  • data
  • on
  • his
  • screen
  • and
  • saves.
  • Changes
  • are
  • committed,
  • overwriting
  • Shahla's
  • changes.

Obviously

this

isn't

good;

when

Dave

finally

submits

changes,

we

need

the

app

to

detect

that

someone

else

has

changed

the

data,

and

to

handle

the

situation

appropriately.

Two

aspects

to

doing

this

are:

# *Detection* \- how to detect a concurrent update # *Handling* \- what to do if we detect a concurrent update We'll take these in reverse order:

  1. Detection - how to detect a concurrent update
  2. Handling - what to do if we detect a concurrent update

We'll take these in reverse order:

Panel

Example Situation

indent
11
Panel

Handling a Concurrent Update Situation

indent
1
1
There are three approaches to handling a concurrent update situation:

# _Last commit wins_. This is the situation described above, where Dave wipes out Shahla's changes. This is what we're doing most of the time in our apps, and it does not involve any detection of a concurrent update.
# _First commit wins_. In this scenario, Dave would come back from lunch, attempt to save his changes, and see an error message "Someone else has changed the data. Your changes have not been saved". Dave's changes would not be saved to the DB. This does require detection of a concurrent update.
# _Merge_. Here, Dave would be presented with a message telling him that someone else had changed the data, and would be provided with a UI to give them a way of merging his changes with Shahla's changes. This does require detection of a concurrent update.

Unless there's a clear business requirement for the merge option, I think we need to take the second approach, "first commit wins". In order to pursue this approach, we do need to have a mechanism for detecting concurrent updates. Which leads to...

...