Multiuser strategies for record updates with WebServer applications

[GordonF]

I'd be very interested to know what strategies people employ to manage potentially concurrent record updates. Being session based and given the vagaries of internet connections, I wouldn't use any actual record locking, in fact I don't use standard record locking in my multiuser desktop applications, I use a record hold control file to the same effect.

I realise that some multiuser application really don't need records to be held as they tend to partition off users to their own areas, however more general purpose systems run a real risk of data loss if record updates aren't protected in some form.

While I'm happy with my reliable approach for desktop apps, I'm also looking at optimistic locking, which is actually no locking until it is time to commit changes. The problem is that it is late in the day to discover someone got there first and your updates will overwrite their update or yours will be lost, merging changes is only a likely partial and potentially confusing alternative to the first two choices.

Therefore I think the approach I will take is extend my current locking strategy to use the sessionid (am I correct in believing this remains constant for the duration of a user's session?), that way the web users and desktop users can operate on the same data in harmony. In effect I will hold a record via my hold table if it is not already held. If it is indicated as held by a sessionid I will check the session is still active, if not I will purge that session's locks and lock the record for the new requester. When a record is updated or the update process is cancelled I will release the lock. I will also release all locks for a session at session timeout or user logout. The webserver would also purge all locks at start-up and I could also have a housekeeping background thread checking for litter, as in locks from no longer active sessions but this shouldn't be required if I get the rest right.

Before someone says don't lock/hold a record (real or via my method) I should say my clients deal with medical records and arbitrarily writing over changes to data is simply not an option.

Please feel free to comment, I'm not afraid of help or criticism.

I seem to have posted a few messages in the last few days, my excuse is I'm new to WebServer and this forum so please tolerate my posts, hopefully they aren't banal.

Gordon

[Bruce]

>> am I correct in believing this remains constant for the duration of a user's session?

yes, although it usually changes when the user logs in or out. (a session exists even if the user does not log in.)
But in your context it sounds like the user will be logged in, and assuming that to be the case it won't change.

You will need to include your tidy-up code in the WebHandler, NotifyDeleteSession method, and you should also add code to the NotifyChangeSession method.

Cheers
Bruce

[GordonF]

Thanks Bruce, without wishing to sound dim what does the NotifyChangeSession do and when is it called in the context of ending a sesssion?

I was also planning to use the webserver ._DeleteSession as a tidy up point, does this make sense?

Cheers
Gordon

[Bruce]

<< I was also planning to use the webserver ._DeleteSession as a tidy up point, does this make sense?

While it makes sense (in the sense that I can understand you thinking that's a good place) it is not the correct place to put your code, for two reasons.

a) code in the WebServer procedure runs on the WebServer thread. Thus you want to limit work here to as little as possible. By contrast work in WebHandler happens on another thread, so it's better to do the work there. Hence the correct method (NotifyDeleteSession) there. In NetTalk 12, if you are using Memory tables, you can simply add them to th WebHandler / Actions button and the necessary work will be done for you.

b) If you end up running your app under the multi-site host, then embed code in the WebServer procedure will not run. (with the excepetion of code in the INIT method, before the short-return.) So embedding in the WebServer creates probably bugs (in this case memory leaks) in the future.

>> what does NotifyChangeSession do and when is it called in the context of ending a sesssion?

It's not called int eh context of ending a session. It's called in the context of changing the session ID. That can happen when a user logs in, or out, to prevent session-fixation attacks.

Cheers
Bruce

[GordonF]

Thanks Bruce, I'll play around with it during the next week or two.

Gordon