Re: Update view of database on multiple web clients

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

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

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. ... Is there are a "standard" way of doing this? ... satisfactory for most circumstances, maybe you should put your data in a ...
    (comp.lang.java.programmer)
  • 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)