RE: MVC Architecture and transactions

Just a quick note here...

But if you already journal your files, then using commitment control SPEEDS UP your application.

You can find out the technical details in the "Striving for Optimal Journal Performance on DB2
Universal Database for iSeries" but basically, when using commitment control the writes to the journal
can be bundled into fewer physical I/Os.

HTH,
Charles

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx] On Behalf Of DeLong, Eric
Sent: Tuesday, August 21, 2007 2:51 PM
To: RPG programming on the AS400 / iSeries
Subject: RE: MVC Architecture and transactions

Fair enough...

In my current environment, we're already journaling for HA,
so given THIS environment, commitment control starts looking
more desirable.... My past experiences in IT have never
included the use of commitment control, but I fear that this
is just another example of our reluctance to change our minds
about long-held prejudices. For example, just how much
overhead is incurred on a modern i5 when using journaling? I
suspect that with today's speedy CPUs tht the incurred
penalty is quite small. I also suspect that more shops than
ever are using HA replication...

My personal view on this is that I need to understand this
technology better, and that my toolbag has plenty of space in it.

Thanks for the feedback.
Eric

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Joe Pluta
Sent: Tuesday, August 21, 2007 1:03 PM
To: 'RPG programming on the AS400 / iSeries'
Subject: 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


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




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

This e-mail transmission contains information that is intended to be confidential and privileged. If you receive this e-mail and you are not a named addressee you are hereby notified that you are not authorized to read, print, retain, copy or disseminate this communication without the consent of the sender and that doing so is prohibited and may be unlawful. Please reply to the message immediately by informing the sender that the message was misdirected. After replying, please delete and otherwise erase it and any attachments from your computer system. Your assistance in correcting this error is appreciated.