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

[Jan-Erik Soderholm]

JF Mezei wrote 2014-02-18 23:43:
> On 14-02-18 17:33, Jan-Erik Soderholm wrote:
>
>> 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?
>
> The app would notice an expired lock, and issue mssage to user.
>
>
>> 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. :-)
>
> This is the WIndows Weenie type of thinkink as they were brought up with
> single user systems and never really understand the need for locking.

Besides of that beeing a bucket full of bullshit,
it very much depends on the actual application and making the assuption
that only one user at a time is accessing a specific record is in many
cases just "good enough".


>
> But if you are building a serious application, can you really afford to
> ignore locking ?
>

Define "serious". But in the general case, yes.

>
>> 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.
>
> Won't help if 2 widthdrawals for the total amount in the account were
> made due to lack of locking. The account balance will show "$0" despite
> you having handed out the balance twice and it would take a long time to
> trace it back.

As I said, it depends on the application. Exactly where was a *bank*
application mentioned? Anyway... :-)

In your example two widthdrawals will still be made and the
balance will show two widthdrawals made. Yes, the balance will
be a bit lower then either of the two users expected, but there
is no reason both are not made correctly. That is a matter of
transaction handling in the back-end servers.

The client is not sending the *balance*, it is sending an widthdrawal.
It is up the database server to make sure that both widthdrawals
are completed successfully and correctly.

If the first widthdrawal is large enough to block the second, that
could generate an error "not enough balance" or similar.

There is no reason this would create any inconsistency in any case
and the record doesn't *have* to be locked between display and commit.

>
>> But, *that* has little with the web to do. Any ordering application
>> could behave in the same way. :-)
>
> Yes it does because of the stateless web transaction model.
>

No, it doesn't. I ment the "cart" way of reserving items before
commiting the order. That is independant of the interface.

Jan-Erik.