RE: MVC Architecture and transactions

From: DeLong, Eric

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.

Whoa, whoa, whoa. I'm not saying it's not a worthwhile feature. In my
original post to Charles, I talked about having an option for *NONE, but
just as an option. There are definitely circumstances where commitment
control may be required, circumstances ranging from high availability to
multiple-tier databases. I'm just saying that the nebulous "standard
transaction" in which maybe five to ten files are being updated doesn't
necessarily warrant the overhead of commitment control.

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.

Yup. And I personally have never had a single circumstance where a customer
needed a more reliable database on the System i. That's not to say
databases don't crash. Back in the day I worked on some databases that used
networked tables (where the RRN was actually the link from one file to
another). Lose one of those tables and you're in for a very bad day. But
I've never needed commitment control on a System I for any normal
application.

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....

It's a design decision. If you want the overhead and you don't trust your
application, then that's fine. But like so many other things in IT, it's
not necessarily a good thing to have just because you can.

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.

Sometimes, sure, but if it's a matter of an RPG program updating a handful
of files, I can indeed identify all possible potential failure points,
ranging from record locks to abnormal terminations, and I can code for all
of them if necessary. Yes, there are circumstances where commitment control
may be needed, but in my experience those are the exception rather than the
rule.

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.

In order to use commitment control, you have to journal the files. The
system management overhead for journaling is significant, and in many cases
probably outweighs any benefits from commitment control.

Again, commitment control is not intrinsically bad. However, it's not
intrinsicially better than no commitment control, either. Like everything
else in IT, it's a business decision, not a religious one.

Joe