RE: framework question -- JAVA400-L

> From: Simon Coulter
> 
> ALL business applications should be using journalling for forward
> recovery and any application that has transactions that affect more
> than one file should be using commitment control. No excuses!

>This is the type of bollix I'd really like to keep off this list.

>Having journaling and commitment control may indeed be more reliable
than not having them.  However, there is a price to pay in terms of disk
space and performance.  That price is essentially the cost you pay for
insurance against hard disk crashes.

In my experience, most of the strangest architectural decisions have
been taken because of the blown up performance concerns. Yes, there is a
price to pay. But, first of all, the benefits go far beyond simple
crash-protection - I don't think I have to reiterate the arguments that
have been raised in favor of CC in this thread alone. Secondly, it would
be nice if we could detail and quantify those performance concerns. 

There are basically two types of price one pays for having CC, both
journal-related: slowdown of batch processes and increase in the system
resource utilization. Now, slowdown of batch in the journal environment
is almost always caused by poor design; 9 times out of 10 long-running
batch can either be multi-streamed, or, if it is not part of the
transaction input (night batch or similar) it can be run with CC
switched off (HA journal performance option for the journal switched
on). One must remember to correctly allocate journal receivers to avoid
them turning into a bottleneck, etc. Increase in the system resource
utilization, provided that the system design is OK (ideally, each
business transaction should be represented by a single DB transaction)
and receiver allocation is also OK, rarely goes beyond 15%-20%; and in
my view, this is a small price to pay for the obvious benefits received.
By the way, running popular bits of middleware (such as MQS or
WebSphere) on iSeries has far more significant performance implications,
and nobody seems to be particularly concerned.

Additionally, the above costs have to offset by the hidden costs we
often pay for the in-house CC replacements. I know a system where half
of the tables have been changed to FRCRATIO(1) in order to avoid the
potential loss of information and immediately expose records being added
to other system jobs. I know for a fact that the performance penalty of
such a solution is much higher than that imposed by journaling/CC.
Triggers, widely used to provide in-house CC-like functionality, often
turn into notorious performance hogs - triggers setting LR on at exit
are very common.

Given the average quality of the iSeries programmers CC is probably a
winner, rather than a loser, on the performance front.

Lo