RE: Additional Journaling/Commitment Control Info From IBM

> From: Paul Holm
> 
> Group....  FYI if it helps anyone.  Larry is considered a premier
source
> for HA, recovery, etc on the 400

Paul, thanks for this.  One of the problems with experience is that it
can go out of date.  It seems that my knowledge from seven or eight
years ago is a bit stale.  I think Larry might be stretching the point a
little on the "performance enhancement" issue - I'd like to see some
real numbers on performance, especially based on isolation levels - but
it's clear that the arguments FOR commitment control are at least
gaining ground on the reasons against it, if indeed they haven't already
surpassed them.

At the same time, let's still be clear that it's a business decision.
There are costs to be weighed against benefits.  As I pointed out, a
system that is mostly static data (few though there are) would likely
not benefit from commitment control.  And as Marc points out, commitment
control is not a slam dunk to implement - transaction boundaries get
pretty important, and it's still a bit of an art.

It's not clear to me that you would actually combine every update done
by an order (including inventory, A/R, sales, and so on) into a single
commitment boundary, and if not, where you would draw the line, and if
you did draw a line, what would happen in the case of a catastrophic
failure and how that would be different from no commitment control at
all.  But I'm willing to learn!  And since it's really important in the
world of JDBC and especially EJB, I think it's important to this list.

Joe