onunload when app quits - time too short

[Joakim Braun]

Unonload doesn't get much time when quitting the browser. So how can you
do time-consuming actions then?

I'm doing a web-based MySQL interface. Records are presented as tables of
links. The problem is check-in/check-out: Who can change which record when?

So far I have a "session" approach: on login, user gets a session ID valid
for some amount of time. Editable records have a database column for storing
session ID:s. When user tries to open a record, we check its session ID
column for unexpired sessions. If there are none, user gets an editable
document that he can save back to the database, and user's session ID gets
written to the column. If there's an unexpired session going on with the
record, user gets a non-editable document with a "document busy" message.
When user closes editable document, user's session ID gets cleared from the
database record by loading a PHP page. This is triggered by the onunload
event.

This obviously wont work in case of crashes. It also doesn't work if user
quits browser application: The unonload doesn't get enough time then to load
the PHP page.

Ideas? Design comments? (sessioning is ugly, but how else can a
browser/database interaction be handled?)

Joakim Braun

 

[Randy Webb]

Unonload doesn't get much time when quitting the browser. So how can you
do time-consuming actions then?

I'm doing a web-based MySQL interface. Records are presented as tables of
links. The problem is check-in/check-out: Who can change which record when?

So far I have a "session" approach: on login, user gets a session ID valid
for some amount of time. Editable records have a database column for storing
session ID:s. When user tries to open a record, we check its session ID
column for unexpired sessions. If there are none, user gets an editable
document that he can save back to the database, and user's session ID gets
written to the column. If there's an unexpired session going on with the
record, user gets a non-editable document with a "document busy" message.
When user closes editable document, user's session ID gets cleared from the
database record by loading a PHP page. This is triggered by the onunload
event.

When you check the session ID, check its age. Have a second column in
the mySQL database that has the time the last session was issued. If
it's expired, then disregard it and continue on as if there was no session.

 

[Fred Oz]

Ideas? Design comments? (sessioning is ugly, but how else can a
browser/database interaction be handled?)

This is a very common database problem that has been solved a thousand
times before. It is not really appropriate to this forum since it is
almost entirely a server-side issue. The fact that the web is
stateless is not really the issue, it just highlights the problem of
updating databases in real time when real users are involved. In a
stateful environment you know that the user's terminal is still
connected and that they are still logged in, but you don't know if they
are still there or actually doing something.

The issue is if you lock a record for update, how long do you keep it
locked for? The way around it is not to have users directly updating
the database, they should be accessing some update function that
does the actual update, then let business rules decide what to do.

This may be too complex for your application, try this: grab the
database value, then let the user modify it. When the user commits
their change, see if the value in the database is different from when
they checked-out the record. If so, let them know, tell them the new
value and ask what to do. If the value is still the same, update it.

How often you get collisions where different users try to update the
same record can usually be estimated before hand. Try and work it out,
and have your users approve an appropriate method of resolution. If
the chance is low, the solution suggested above should be fine. But if
the chance is high, you'll need something else.

Cheers, Fred.

 

[Joakim Braun]

<snip>

When you check the session ID, check its age. Have a second column in
the mySQL database that has the time the last session was issued. If
it's expired, then disregard it and continue on as if there was no

session.
<snip>

Well, I already have session timeouts in the way you describe. But to reduce
traffic and user annoyance I'd like to have sessions of at least 15 minutes.
That's a long wait for a fake-"busy signal". Or do you mean a column in each
record that says when it was opened, with a shorter timeout?

Joakim Braun

 

[Joakim Braun]

"Fred Oz" <[email protected]> skrev i meddelandet

This may be too complex for your application, try this: grab the
database value, then let the user modify it. When the user commits
their change, see if the value in the database is different from when
they checked-out the record. If so, let them know, tell them the new
value and ask what to do. If the value is still the same, update it.

<snip>

Hmmm, yes - in fact I could POST the new values to a PHP script via an
iframe in the form, instead of posting the form directly. Though another
read access would be involved, but this will never be something with
hundreds of users involved.

Thanks!

Joakim Braun

 

[Joakim Braun]

Still, the original onunload question remains. How can you meaningfully use
unonload when it's triggered by quitting the browser?

Joakim Braun

 

[Michael Winter]

Still, the original onunload question remains. How can you meaningfully
use unonload when it's triggered by quitting the
browser?

You can't. Opera only fires the unload event when you navigate to a page.
Refreshing or closing the tab or browser does nothing. On the other hand,
Mozilla, Netscape, Firefox, and IE respond to all three. But, if I
remember correctly, the first three are more restrictive regarding what
you can do when the browser is closing.

In any case, trying to invoke a new remote connection when the browser is
closing is a very unreliable thing. During that time, all the browser
should be worrying about is the freeing of resources. Acquiring new ones
is probably not something that developers would try to accomodate. Why
should they? It doesn't make sense.

Mike

 

[Joakim Braun]

You can't.

<snip explanation>

Clear enough. Thanks for putting me off a bad track.

Joakim Braun

 

[Joakim Braun]

The answer still remains that the firing of onunload is
unreliable, so you would not (attempt to) use it for such
functionality.

OK, then not. Thanks.

Joakim Braun