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

[David Froble]

Paul Sture wrote:
> 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.

Ya know, I never cared to explore the issue, but it's my guess that the 
"shopping cart" information, at least in some implementations, is stored 
in "cookies" or similar on the client system, and not on the server.

For example, I've been on web sites, and placed items in the "shopping 
cart".  However, if I then got on the web site from a different 
computer, the shopping cart was empty, but not on the original client 
computer.

Or perhaps the server can identify the incoming connection, even through 
a NAT router.  Like I wrote, I didn't care to investigate.

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

As always, "it depends".

My experience is mostly in wholesale distribution, where there is 
usually repeat customers, and substantial customer information on file. 
  In such a situation, there is a smaller set of potential users. 
Retail on the other hand is a whole different ballgame.  Think Amazon 
and such.

As an example, one customer of a customer has their own web site, and 
accepts orders from retail customers.  When an order is placed, they 
then connect to the Codis customer and send in the entire order for 
fulfillment in one transaction.  So the Codis application does not have 
to deal with waiting on buyer responses.