[Info-vax] OT: Record locking for web transactions

[Jan-Erik Soderholm]

JF Mezei wrote 2014-02-17 21:13:
>
> With RMS, things were simple. the process running the UI also had the
> record locks. If process dies, any/all locks are released.
>
> How does one handle this with web transactions ?
>

The web is basicaly stateless, so you never keep locks from one
access to another. In most cases you simply rely on that two users
doesn't touch the same record. If you realy care, you can let
your server application check if there have been any update
since it was read. Or simply save the last "submitted" update
relying in that the last update should be the most correct.

Two users updating the same record is to the server just like
*one* user doing two updates in a row. The server can normaly
see the difference. If you do not use some session technology.


> Say use pull up a record to update it. When you read the record, you put
> a write lock on it to prevent others from modifying it while the first
> user does. In normal circumstances, the user press "Submit" and the
> record is updated and the lock is released.
>
> However, there is no garantee the use will press Submit, and the user
> could very well close that web page, turn off his PC etc.

If you realy keep locks, use timeouts. Note that there is no
way for the server to notice if the user is simply thinking
about the update or if he has switched of his client. When the
screen have been sent to the client, the client is "gone".

> So what sort of strategy is used to handle locks taken by a user who
> disapears without warning and never completes the transaction ?
>

Either you just doesn't care, if the user goes away, the record is
just as it was when read. Or (if you are working with some session
technology) you can save the state (like in a "shopping cart")
and when the user logs i next time the state is as before the
last screen was displayed.


> (this in a context of an app written in PHP accessing MySQL, but looking
> for generic strategy to handle this).
>

The generic strategy is "it depends". The specific strategy is
largly depening on the specific application.

Jan-Erik.