RE: MVC Architecture and transactions

Yep, the PPRQ is nice, but have you seen this?

http://www.redbooks.ibm.com/abstracts/tips0623.html?Open


Charles

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

True, except that we already had the PRPQ Cache Journal
whatchamacallit..... I think this gives us the same
asynchronous cache commit logic as commitment control.

That is a good argument for those shops reluctant to
re-examine their beliefs, though....

Eric

-----Original Message-----
From: rpg400-l-bounces@xxxxxxxxxxxx
[mailto:rpg400-l-bounces@xxxxxxxxxxxx]On Behalf Of Wilt, Charles
Sent: Tuesday, August 21, 2007 2:20 PM
To: RPG programming on the AS400 / iSeries
Subject: 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.

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