Those are good questions, Walden. To be more clear, I was benchmarking purchase orders - not sales orders, but your question about updating inventory is relevant. Some of this has been discussed at length on one of the lists. We could search the archives.
My understanding and position now is that in cases where you write a record to one table and update another by a single transaction, you can for all practical purposes, guarantee Atomicity, Consistency, Isolation, & Durability, with RPG RLA by first getting a lock on the row you're updating, write the transaction, check for a write error, then conditionally update the locked record if no error occurs on the write.
On the other hand, if you are relegated to only using SQL ...
-Nathan.
----- Original Message ----
From: Walden H. Leverich <WaldenL@xxxxxxxxxxxxxxx>
To: Midrange Systems Technical Discussion <midrange-l@xxxxxxxxxxxx>
Sent: Thursday, August 20, 2009 8:55:26 AM
Subject: Commitment Control (was: Modernizing applications (was: Explaining single level store tonon ipeople))
Users press enter, a line item is created, the item is added to a
table on the screen.
And when these orders are created the only record written is to the
order-detail table? Are you not allocating inventory? Updating the
header with an order total or line count? If there is only one update
ocuring then yes, commitment control would be redundant.
But at some point you must update multiple rows somewhere. If you're not
allocating inventory at order time (I can understand that) then you must
do it at some point, no? In that case, you'd have to make the line as
processed, and decrement the inventory. Both those operations can't
happen atomicly without commitment control. It's _possible_ that you'll
decrement inventory and not mark the line processed (or mark the line
processed and not decrement inventory -- depending on the order you do
things), if, for example, the machine crashes between step 1 and step 2.
Without commitment control that won't get fixed.
-Walden
midrange.com
