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

[Jan-Erik Soderholm]

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.