Hi Joe,
I too am in the "rarely (if ever) used commit control" camp, but I would not go so far as to say it's not a worthwhile feature. It IS a standard transactional control with most database servers, and most other platforms use this feature to improve the reliability of the database and the transactions it supports. If you're saying that System i does not need this extra safety net, I might have to disagree. The best application design in the world could still benefit from a reliable, well proven, efficient means of undoing a failed transaction....
Why do transactions fail? There are probably an infinite number of answers, some of which can be controlled by the developer, and some of which are completely inexplicable. Of key importance is the developer's ability to identify potential failure points, and to devise the means to correct these failures.... I'm sure you'll agree that, despite our best efforts, it is sometimes impossible to understand ALL the potential failure points.
People talk about checking everything out up front as a way to avoid commitment control, and I won't argue that this is incorrect. However, is that the right approach in all situations? This is, to me, a lot like the MONITOR opcode. The rule of thumb for Monitor is "if you expect high failure rates, monitor becomes inefficient and should be replaced with an explicit test. Commitment control grants protection for the problems that were never considered in the first place. Is this bad? Testing for a thousand possible failures for an event that might never happen seems a bit overkill in most cases, so Commitment control seems to be more efficient for handling these "once in a blue moon" failures.
JMO,
Eric
-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Pluta
Sent: Tuesday, August 21, 2007 11:44 AM
To: 'RPG programming on the AS400 / iSeries'
Subject: RE: MVC Architecture and transactions
Actually, the same argument can be made for ANY application. If you update
a shop order but don't update the inventory, bad things will happen. The
same holds true for A/R transactions or orders or anything else, really. In
fact, in my experience most business transactions are more than CRUD, and
yet many companies ran fine over the years without commitment control,
primarily because the System i and its DB2 database are so reliable.
If the program is written correctly, the files will get updated. If the
program is not written correctly, commitment control won't help. The only
thing commitment control buys you from a file update capability is when an
I/O error occurs, and frankly, when THAT happens on a System i, you have
much larger problems.
Joe
From: Nathan Andelin
As Aaron points out, a lot of RPG programmers don't do any
COMMIT/ROLLBACK.
If so, they've never worked for a bank. If a customer gives cash to a
teller, you'd better make sure that when you add a record to the
transaction history file, you also update the balance of the person's
account, and update the teller drawer file, and update the general ledger,
and so forth. Otherwise it's going to cause a lot of trouble when someone
tries to figure out why the various account balances and histories are out
of sync.
However, if your application is just basic create, read, update, delete of
single records in a single file, commit/rollback would be over-kill.
Nathan.
__________________________________________________________________________
__________
Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail,
news, photos & more.
http://mobile.yahoo.com/go?refer=1GNXIC
--
This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list
To post a message email: RPG400-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/rpg400-l
or email: RPG400-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/rpg400-l.
midrange.com
