From: rf on
Laser Lips wrote:
> I'm working with a technology called CACHE which is made by
> Intersystem�s.

So why don't you ask them how they do what you wish to do?

> I need to do a couple of things when the browser closes.
>
> I need to log the user out of the system.
> I need any locks in the CACHE database to be unlocked.
> CACHE will not know when the browser closes because like any server
> side technology, it does not have a permanent connection to the
> browser.

Exactly.

> I can't have Ajax polling the server because there will be to many
> server calls.
> I really need these locks to be taken off immediately.
> If the user exists using the log out buttons then these locks are
> removed, it's just when they hit the [X] that I can't catch.

Doomed to failure.

What if the user simply turns their computer off? What if there is a power
failure?

What if their browser crashes? What if the operating system crashes? What if
they simply re-boot?

What if their internet connection fails?

What if they throw their computer out the window?

You will *never* be able to determine if any of these things have happened,
so why bother checking if the browser has "closed". You can't, reliably. You
need to find some other method of cleaning up your server side processes.


From: Laser Lips on

> What if the user simply turns their computer off? What if there is a power
> failure?
>
> What if their browser crashes? What if the operating system crashes? What if
> they simply re-boot?
>
> What if their internet connection fails?
>
> What if they throw their computer out the window?
>
> You will *never* be able to determine if any of these things have happened,
> so why bother checking if the browser has "closed". You can't, reliably. You
> need to find some other method of cleaning up your server side processes.

OK, I get your point. Will think of something.

Graham

From: David Mark on
Laser Lips wrote:
>> What if the user simply turns their computer off? What if there is a power
>> failure?
>>
>> What if their browser crashes? What if the operating system crashes? What if
>> they simply re-boot?
>>
>> What if their internet connection fails?
>>
>> What if they throw their computer out the window?
>>
>> You will *never* be able to determine if any of these things have happened,
>> so why bother checking if the browser has "closed". You can't, reliably. You
>> need to find some other method of cleaning up your server side processes.
>
> OK, I get your point. Will think of something.
>

As mentioned, a server side session timeout is the best bet.
From: Evertjan. on
David Mark wrote on 02 mrt 2010 in comp.lang.javascript:

> Laser Lips wrote:
>>> What if the user simply turns their computer off? What if there is a
>>> power failure?
>>>
>>> What if their browser crashes? What if the operating system crashes?
>>> What if they simply re-boot?
>>>
>>> What if their internet connection fails?
>>>
>>> What if they throw their computer out the window?
>>>
>>> You will *never* be able to determine if any of these things have
>>> happened, so why bother checking if the browser has "closed". You
>>> can't, reliably. You need to find some other method of cleaning up
>>> your server side processes.
>>
>> OK, I get your point. Will think of something.
>>
>
> As mentioned, a server side session timeout is the best bet.

Even better, do not keep things "open" between browser and server during
the session but store the intermediate result if you don't want the the
result in the database until your user signals a completion.

On start of a new session ask the user if he wants to resume his work. m/f


--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Laser Lips on
On Mar 2, 2:32 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote:
> David Mark wrote on 02 mrt 2010 in comp.lang.javascript:
>
>
>
> > Laser Lips wrote:
> >>> What if the user simply turns their computer off? What if there is a
> >>> power failure?
>
> >>> What if their browser crashes? What if the operating system crashes?
> >>> What if they simply re-boot?
>
> >>> What if their internet connection fails?
>
> >>> What if they throw their computer out the window?
>
> >>> You will *never* be able to determine if any of these things have
> >>> happened, so why bother checking if the browser has "closed". You
> >>> can't, reliably. You need to find some other method of cleaning up
> >>> your server side processes.
>
> >> OK, I get your point. Will think of something.
>
> > As mentioned, a server side session timeout is the best bet.
>
> Even better, do not keep things "open" between browser and server during
> the session but store the intermediate result if you don't want the the
> result in the database until your user signals a completion.
>
> On start of a new session ask the user if he wants to resume his work. m/f
>
> --
> Evertjan.
> The Netherlands.
> (Please change the x'es to dots in my emailaddress)

Not as simple as all that.

While a user has a record open that record is locked to all other
users.
The mechanism we use to lock a record is CACHE's built in one.
We could use temporary tables to flag locked records and use temporary
storage until user is ready top commit data back to the DB but this
means a whole software rewrite and many site updates, so it's out of
the question.

All records are unlocked after 15 mins or a session timeout, but the
intermittent waiting is a real killjoy.
Graham