[Info-vax] OT: Record locking for web transactions
Paul Sture
nospam at sture.ch
Wed Feb 19 01:06:49 EST 2014
On 2014-02-17, David Froble <davef at tsoft-inc.com> wrote:
> Jan-Erik Soderholm wrote:
>> 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.
>
> This is also my understanding. Basically, you're talking about a
> different environment and concepts than what we all grew up with.
>
> Note, all this is assuming that you're working with users running a browser.
>
> Let's say that you have a web site selling chocolates.
>
> You get an incoming request. A user wants to see what you have.
>
> You prepare a page showing your inventory, and sent it to the user. At
> that time, you have no idea if the user will ever be back. Maybe he
> found chocolate elsewhere, and was just comparing.
>
> Next, you get another connection request, and it contains the page info
> you sent out, and an order for various products. (Let's leave out
> credit card payment for now.) At this time you actually have something
> to do. You extract the information, name, shipping address, types of
> chocolate, quantities, basically what you need to process an order. So,
> you can now read and lock data, update, and write, and whatever else
> required.
But most web order forms only deal with one order item at a time, which
is where adding them to a shopping basket is a useful device.
The customer builds up the shopping basket contents one item at a time
which means it can work in a stateless environment quite easily; the item
either hits the shopping basket or not and the customer gets the chance
to review the contents much later, even days later.
The when the customer gives the go ahead the whole thing, including payment
can take place as an integral transaction.
> There is no connection between transmissions from the client, except
> return data from whatever you sent out. So the first page you sent out
> should have whatever you need to process the customer's order.
>
> This is a rather simplistic explanation, and I'm sure there is more that
> can be done. But the key is "stateless transactions".
>
> Frankly, I think that it's a big step backwards, sort of like the old
> IBM terminals where an entire form was filled out before sending
> anything to the computer, but even worse. But nobody is asking me.
The classic IBM approach was to read the appropriate records *without
lock*, display the form and then when the user sent the completed screen,
re-read those records again *with lock* into different buffers and compare
the buffers. If the buffers differed then some other user or process had
changed the contents between the two reads and you were supposed to abort
the transaction.
Yes, we thought it was big step backwards and had many a discussion about
ways to ease the pain of saying to someone over the telephone "Yes we have
it in stock / do you want to confirm? / oops it's not available any more".
> Now, if I was designing the concepts, it would be something more like a
> "connected terminal", perhaps some code that ran on the client system,
> and communicated back and forth with the server. What do you do when
> someone turns off their terminal and walks away? Perhaps you cancel any
> partial transactions? Similar could be done, with timeouts and such.
> First timeout, "do you need more time?", and second timeout trashes the
> entire thing.
>
> Or have an open socket connection, and if it goes down, trash the entire
> thing, sort of like with the old modems, lose carrier, and you lose your
> loged in process.
Tying up resources is a problem, and some folks will leave a screen open
"just because it looks nice" ...
> But again, nobody asked me ....
--
Paul Sture
More information about the Info-vax
mailing list