Re: Update view of database on multiple web clients


"David Segall" <david@xxxxxxxxxxx> wrote in message
news:v4t80210dlds9o0fd3uj9oekpgtdr7trrf@xxxxxxxxxx
"Rhino" <no.offline.contact.please@xxxxxxxxxx> wrote:


"David Segall" <david@xxxxxxxxxxx> wrote in message
news:kda8029d3ho7albt7ih5gju0qbmiere932@xxxxxxxxxx
I have been asked to build a collaborative web application. It is
basically equivalent to having multiple web browsers accessing a
record in a database and, when one user alters the record then all the
browsers that are viewing the record should immediately see the
altered record. The problem is simplified because the users log into
my application and all the users in one group want the same record
although there can be many groups logged in.

I think I would like to use JSF for the application and use
XMLHttpRequest to update the database. My current thought is for all
the browsers to issue an XMLHttpRequest when the page is loaded and
for the server to reply to it with the new data and the new data's
location when an update request is received from a client. Each
browser would then issue the same request as the one they issued on
load.

Does the above sound as though it could work? Do you have a better
idea? Is there are a "standard" way of doing this? TIA

I'm not sure if what I'm about to say will be relevant to you but the
situation you describe is a well-known issue in the database world. In a
database environment, potentially hundreds or thousands of users could be
trying to access the same piece of data.

Database people long ago agreed that it was a very bad idea (in most
cases)
for anyone but the updater of a piece of data to see the update until it
had
been committed, i.e. the updater is satisfied that the update has worked
and
that it really ought to be made. At that point, the updater's application
issues a commit, which works something like a save and writes the update
to
the database, and then the data becomes available for the rest of the
world
to see. In the meantime, anyone else who wanted to see the data would have
to wait until the lock was released and could potentially time out
waiting.

Now, the actual details are somewhat more complicated and vary from one
database vendor to another, but that is the gist of it. That brings me to
my
suggestion: since this problem has already been well thought out in the
database world and solutions have been worked out that are generally
satisfactory for most circumstances, maybe you should put your data in a
database and let each of the various users of the data access it via the
standard locking mechanism provided by the database? That relieves your
application of most of the work and leaves it in the very capable hands of
the database.

That, in my opinion, would be the "standard" way of handling the problem.
In
fact, I'd be extremely reluctant to do it any other way unless you are
prepared to write your own code that does all the same things the database
does anyway. And if you did _that_ I would question why you wanted to
reinvent the wheel by re-writing all sorts of code that already been
thoroughly tested and well-proven in the database.

You are absolutely right. The standard way of handling the problem in
the database world is to pretend that it does not exist. If two users
try to alter the same field in a database at about the same time the
second user's version will prevail and neither user will be informed
of the other's attempt to alter the field. This is usually acceptable
because the users are considered to be independent and it is not
possible to decide which of them has the correct value.

I'm not sure which databases you have used but your description does NOT
match the database I know best, DB2. In DB2, the lock manager ensures that
two users could never simultaneously hold the update lock for the row
containing the data value; only the user with the update lock can update a
given row. Period. A row held with an update lock would never be seen by any
other user except in the special case of binding with the UR isolation
level; if the second user's program is bound with UR (uncommitted read) he
can _read_ [but NOT UPDATE] any row of any table, even a row that is
currently locked for update whose update has not been committed yet. [Using
UR is risky: the second user might see the row after it has been updated but
not committed, make a decision based on the value in that row, and then find
that the update has been rolled back because the first user chose not to
commit it; that could render the second user's decision inappropriate if the
data value that was the basis of that decision was inappropriate.] In DB2,
the second user [and any subsequent users] could not see an uncommitted
update except with the UR option: if they weren't using UR, they would have
to wait until the first user committed the update before they could see the
updated row and they could time out waiting for that to happen.

I don't know how locking works on any of the other databases but this is the
way DB2 works, in a nutshell. (It's actually a good bit more complicated
than I've described if you consider "real" locks and "intent" locks,
tablespace locks, etc. but I've given you the gist of it.)

In my application the users are collaborating to update the record and
they all need to discuss if the latest change is an improvement or if
the old, or some other, value for a field is "better". If two users
happen to update the field at the same time the second users version
will also prevail but the first user must be given the chance to see
it and complain about it. Of course, the integrity of the database
needs to be preserved and my application will use the standard
facilities of the database to ensure that it is.

So, each collaborator works in lockstep with the others, reviewing the same
rows more or less simultaneously and you don't commit the update until there
is a unanimous vote by all collaborators that the update is correct?


--
Rhino


.

Relevant Pages

  • Re: Attempt to de-mystify AJAX
    ... > off or in in each of the browsers to snafu your code, ... In my experience you tend not to be doing any "big stuff"on the client ... application can be developed with JS (no database for a start- but you ... ago) is better than avoiding "modern" technology. ...
    (comp.databases.pick)
  • Re: Back Button
    ... If you are editing data, after you have updated the database, if the user ... document that say when a document expires. ... TEST on a few browsers you want to support. ... versions of IE) and you need to circumvent that by adding more headers. ...
    (comp.lang.php)
  • Re: CSS: a simple layout wont work in CSS
    ... (it is validated as HTML 4.01 Strict) ... think for some browsers, ... to try using span or div to do it. ... can be any image in the database). ...
    (comp.infosystems.www.authoring.stylesheets)
  • Re: Update view of database on multiple web clients
    ... browsers that are viewing the record should immediately see the ... XMLHttpRequest to update the database. ... commit it; that could render the second user's decision inappropriate if the ... the second user could not see an uncommitted ...
    (comp.lang.java.programmer)
  • Re: [PHP] A no brainer...
    ... that once you commit, the data is there no matter what. ... Unless session storage is used to save time in retrieving data, ... I think it would be kind of fun to run some actual tests. ... it makes no sense for a database to be faster than ...
    (php.general)