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

[David Froble]

Jan-Erik Soderholm wrote:
> JF Mezei wrote 2014-02-18 23:07:
>> Concept:
>>
>> I read a record with intention to edit/update it. Instead of putting a
>> traditional "lock" on it, I actually update the record with a field
>> "locked until 15:34". (say 10 minutes from now).
>>
>> The user can then update the date and write it back (at which point, the
>> "locked until 15:34" is erased).
>>
>> If the user walks away, the record keeps the "locked until 15:34" field,
>> but when someone else tries to update the record, it sees the lock is
>> stale and can update the field with a new "lock".
>>
>>
>> Comments ? Could that work ?
> 
> What if the user takes 15 min to think about and update the data
> before clicking the "Send" button? And what if if another user
> updated the data after 12 minutes?
> 
> OK, you can throw an error saying that the data has been changed
> since displayed. Workd OK in some cases.
> 
> I think that most applications simply make the assumption that
> two users will not be updating the same record at the same time.
> And if they do anyway, the last one clicking "Send" will win. :-)
> 
> You can have an transaction log where the support can trace what
> happend in the case of one of the users calling saying that his
> updates never was saved.
> 
> Also, many databases has identifiers in the tables saing who is
> responsable for the actual item and only tha tuser can update.
> 
> So, as I said last time, it depends on the characteristics of
> the actual application. And the "solution" will probably be
> quite sprecific in each case.
> 
> 
>>
>> I know that in the airline industry, the old reservation systems had a
>> similar timer where a travel agent could tentatively book a seat and had
>> a certain number of minutes to complete the reservations to submit it.
>> (during that time, that seat was unavailable to other travel agents, so
>> if you had the alst seat available, you had it for a certain number of
>> minutes).
>>
>>
> 
> That is a good way of doing it in those cases where the user can
> select many items in a "cart" and you do not want it to break (an
> item becoming unavailable) at checkout. Others will se a slightly
> lower in-stock during this time. So you "reserv" the items as long
> as the cart is alive and put the items back in stock if the cart
> timesout or the user empties his cart.
> 
> But, *that* has little with the web to do. Any ordering application
> could behave in the same way. :-)
> 
> Jan-Erik.
> 

Yep.

In Codis, if an order is being entered, talking from a terminal here, as 
each line is entered, the stock is reserved.  Should the order be 
cancelled, the stock is released.

It's a bit tougher with internet transactions.  But, it is a design 
issue, you determine what you will do, and won't do, and then implement it.

But, you're talking about "locking" inventory, not records.  No way I'd 
leave a record lock on while waiting for a response.  You read and lock 
the record, do the update, and write the record.  If you need to 
remember somethat might need to be reversed, that's an application 
issue, not a record locking issue.  Design for it.