RE: framework question

["Joe Pluta" <joepluta@xxxxxxxxxxxxxxxxx>]

> From: Raikov, Leonid
> 
>  I would venture
> to say that the majority of iSeries shops do not use journaling.
> 
> Joe
> 
> This may well be true, but do you have any statistics to substantiate
> the statement? For if it is true, it is truly scary: do you really
mean
> that most of the iSeries shops do not use Commitment Control?

I know from my days at SSA that the vast majority of our clients did not
use journaling.  Journaling a 100,000,000 record history file was simply
too much space, as was journaling an inventory system with tens of
thousands of transactions a day.  Occasionally someone would journal a
file for diagnostic purposes (and once the FBI had us journal a file to
catch some embezzlers).

As to commitment control, why would you use it?  Unlike most systems
where the database goes casters up on a routine basis, DB2/400 rarely if
ever has a database fault.  So as long as you know how to write an
application, you don't need commitment control.  Remember, all
commitment control does is provide an artificial boundary around a
multi-record update.  You can do that yourself in a variety of ways,
such as busy flags or in-process fields.  Especially since, in a
properly designed system, the update is all done in one swoop anyway.
If you write a system where there is operator wait time during an
uncommitted update, you need to find a new career.

For multiple record updates, the choice between commitment control and
your own management is simply one of design.  Using "in-process" records
that are posted by a server has a number of benefits above and beyond
commitment control, whereas commitment control has the benefit of being
relatively easy to implement (until you start mucking about with nested
transactions and the like).

For single-record master files, on the other hand, commitment control is
simply stupid.  Sorry, but there's no better term.  It's unnecessary
overhead that can be handled just as easily by the atomic read-and-lock
capabilities of DB2.  Of course, part of that is the fact that DB2 has
that atomic lock capability, which some other database don't share.

Like anything else, commitment control is a tool.  It can be used and it
can be misused.  It has some places where it is good, and other places
where it is not.  In the broad world of DB2/400-based business
applications, it has been my experience that commitment control is
nearly always overkill.

Joe