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

[Jan-Erik Soderholm]

David Froble wrote 2014-02-19 01:04:
> 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.

Fully agree. The actual *database* locking is for the consistency of
individual transactions. Like "Reserv stock", "release stock",
"commit order" and so on.

There is no difference in this regard between an VT-app from the 80's
and todays iPhone apps. Note that web-apps is "legacy" today. :-)

Jan-Erik.