RE: Commitment Control

To me it's rather straight forward, you use CC to achieve ACID
transactions on i. Atomic, Consistent, Isolated and Durable. That is,
either the whole thing happens or none of it happens, and another
process cannot see a half-baked transaction.

Simple example, you show the user a screen to enter an order, header and
details. Now it's time to save that order, what if you write the header
and the machine crashes (or the job ends, or the program bombs, etc.)
What if it's not just order header and detail, but order header, detail,
ship-to, ship-to-detail, decrement item balances, etc. There is no way
to _guarantee_ that the process will complete successfully and leave the
database in a consistent state w/out commitment control. You can be
"sure", you can "double-check", you can even "promise", but w/out
commitment control, you do not have a system that is guaranteed to be
consistent.

However, there's a cost to commitment control, namely that it will hold
record locks from the time you update a row to the time that you commit
that update. That's not a big deal on the order header/detail scenario,
but if you add in the item-balance table then job 1 will hold locks on
the item-balance row for an item until it's done writing all its updates
and commits, which means job 2 will sit in a lckw state until job 1
commits (or the timeout occurs). If you plan ahead for this then you're
ok, just don't forget about it. Or move updates of shared resources out
of the main transaction scope and into a secondary process (and
secondary transaction scope).

3 rules of thumb for CC:
1) Make your scope large enough to make logical sense, but not so large
as to lock up the entire system.
2) Commit on success, rollback on everything else. That is, if success
then commit, else rollback! NOT If failure rollback, else commit. Plan
for success, all other outcomes are failure.
3) Never hold a commit boundary open across screen calls. That is, you
should start and complete a transaction while the screen is input
inhibit. If you go back to the user with an open transaction something's
wrong.

(Rule 3 is the basis of some debate, but I find it a simple cut and dry
rule)

-Walden