Concurent updates on a value

Question

Hi guys,
Please help me on this. I have a problem and I want to think about it and find the best way to implement it. I will give you a simplified example but similar with what I have:
You have a stock_amt value in one table and there is a procedure that updates and substracts from this stock_amt.
lets say in a store a have a stock amount of 50 items and this procedure, for each sale is subtracting from this value and it is not allowed to go below zero. The process, beside the update, on this column (set stock_amt = stock_amt - x) is doing a lot of other updates on other tables and it total it takes like 0.5 seconds. Everything is fine till I want to execute this procedure by 50 users in parallel.
The initial implementation, to avoid some dead locks and we put a lock on that column (stock_amt) but there where to much waits. we cannot hold that lock for 0.5 seconds.
What will be the best approach for this?
For this stock amt problem, maybe the solution can be a trade like: do not update that column every time but once in a while, by another process or by a materialize view logic.
but what if my column is a critical value like a Prepay balance or bank balance and it needs to be updated in near real time. What will you do?
Thanks

Answer 1

To add to what Iordan posted, besides trying to ensure the same set of tables are updated in the same order you can also look to see if it is possible to place the item quantity on hand value at the end of the transaction, i.e., right before commit. This would reduce the wait for this specific row. The mention of specific row brings up another consideration. OK you have 50 concurrent transactions against the table but are all 50 against the same items? If the transactions hit different items then if you process each item number in a separate transaction the chance of having to wait is greatly reduced. So in fact the process may already be good enough as you are unlikely to have very many sesssions waiting on the same item. This does require item at a time processing.
Go through each and every query/DML statment in the process and make sure each is optimal. After all .40 is better than .50 and on a high use concurrent transaction every little bit helps.
Another consideration, do not calculate the on current on hand quantity at all , but instead read the item storage location table to calculate the value when needed. This eliminates the multiple concurrent update to a single row issue. That is you store items some where and some items will consume multipe bin locations. You pick from these locations and update the storage location bin count information on usage but do not update the item master with the current on hand quantity. You read that on demand.
As Iordan, what you can do depends on business requirements. No one solution fits all.
HTH -- Mark D Powell --