> Yes. In a ERP System, with Stock Control. When a user need to
> updated the quantity of a item.

...

> But if the second transaction knew that the item was being
> updated in another transaction, then waited for the release
> and commit, and conclude the post, without the risk of ‘
> dealock messages’.

You can also avoid "the risk of deadlock messages" by using
a separate stock quantity table where, during normal day-to-
day operations, records are only inserted:
+------------+ +----------+
| stock-item |----<| quantity |
+------------+ +----------+
-1 (1 sold)
-2 (2 sold)
+10 (10 purchased)

Checking the stock quantity sums the relevant records in the
quantity table. Because records are only ever inserted no
update conflict ever occurs. At some useful interval (stock-
take or monthly or whatever) some management process could be
run to consolidate the records in the quantity table (to
prevent the volume causing significant performance issues).

One of the advantages of this arrangement is the ability to
better cope with user interface vagaries. We all know that
users do inconvenient things like leave a record incomplete
for long periods of time (they answer the phone, go to lunch
or whatever. A system such as described above allows you to
avoid blocking access to all other users in the most usual
case (we hope) of there still being stock available to sell.

Of course if you insist on blocking all other users... well
that is why the PessimisticLocking feature is provided.


There are many possible variations on this theme.

--
Geoff Worboys
Telesis Computing