Prev: FAQ Topic - How do I download a page to a variable? (2010-03-02)
Next: Randomator.html
From: Evertjan. on 2 Mar 2010 16:49
Laser Lips wrote on 02 mrt 2010 in comp.lang.javascript:

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

As much as I hate topposting, this full bottomquoting is also not
perfect. So please skip all irrelevant parts, like the signature.
Any good newsreader will do the latter for you automagically.

And start interposting.

> While a user has a record open that record is locked to all other
> users.

So that is clearly not the way to do it. If you cannot use a roll back
mechanism, just do not process the data till everything is ready for the
final datetranfer tot te database.

The record locking should be only miliseconds long.

> The mechanism we use to lock a record is CACHE's built in one.

So if it is a bad system, don't use it.
Is this ASP?
VBS or Jscript?
or is this a com?

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

Your choice. If it is too much work to better the procedure, it usually
is the logical alternative option to keep using the bad and the ugly.

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

Quite so.

You should be able to shorten that timeout to 1 minute, but still ...

> Graham

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)
From: Musaul Karim on 3 Mar 2010 20:07
On Mar 2, 2:58 pm, Laser Lips <loudsphi...(a)gmail.com> wrote:
> On Mar 2, 2:32 pm, "Evertjan." <exjxw.hannivo...(a)interxnl.net> wrote:
>

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

It's almost always a bad idea in web based system to lock any server
resource beyond the span of a single request. This is especially true
if you are going to have enough users to make ajax based polling
unfeasible.

If the data involved here takes a while to edit, then you might
yourself need to implement a more granular locking, i.e. field level?

Like everyone here has already said, there is no guaranteed method the
browser/client connection is no longer available. If you want a
lighterweight polling system, perhaps you could try a raw sockets
connection using Java or Flash? I haven't done any benchmarks to see
how much lighter it would be though.
From: rf on 3 Mar 2010 22:35
Laser Lips wrote:
> 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

It's interesting that the daily FAQ posting of 3.5 hours ago deals exactly
with what you are trying to do.


First  |  Prev  | 
Pages: 1 2 3
Prev: FAQ Topic - How do I download a page to a variable? (2010-03-02)
Next: Randomator.html