Re: framework question

[Simon Coulter <shc@xxxxxxxxxxxxxxxxx>]

On 07/07/2004, at 10:03 AM, Nathan Andelin wrote:

> How would OS/400 commitment control procedures help when the power 
> goes off?
> If a standard file update is interrupted by a power failure, couldn't a
> journaling or commit operation also be interrupted?

The point of commitment control is all records in a transaction get to 
the database or none of them do. That's it. The system guarantee's that 
changes (adds, updates, deletes) to the database are written to the 
journal receiver before they are written to the file. In some cases 
they may not make it to the file for minutes.

So the application updates a dozen records on half a dozen files and 
just before it issues a COMMIT the power plug is pulled by the cleaner 
vacuuming the inside of the computer room. Hard crash!

IPL the system and the machine (as in SLIC not OS/400) will perform 
journal recovery. All changes found in the journal but not found in the 
database and for which a commit entry exists in the journal are applied 
to the respective database files. All entries in the journal that are 
in the database but for which no commit entry exists are rolled back. 
Voila (waalah to the heathens), consistent database.

The only issue now is to determine what transactions were rolled back 
and need to be re-keyed. That is what a commitment control notify 
object is for.

Regardless of Joe Pluta's comments to the contrary you CANNOT do this 
as easily or as reliably using any roll-your-own method. And that is 
not opinion--no amount of gentlemanly conventions such as lock records, 
in-use flags, or other gizmos can compare to the guaranteed absolute 
recovery inherent in the database--especially when remote unit of work 
and two-phase commit is required.

OS/400 users have been spoilt. On many database systems logging (read 
journaling) and transaction isolation (read commitment control) are 
required factors. Arguably because those other systems (and they know 
who they are) are less stable or reliable than OS/400 however the 
legendary stability of OS/400 is no excuse not to do things properly. 
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!

Regards,
Simon Coulter.
--------------------------------------------------------------------
   FlyByNight Software         AS/400 Technical Specialists

   http://www.flybynight.com.au/
   Phone: +61 3 9419 0175   Mobile: +61 0411 091 400        /"\
   Fax:   +61 3 9419 0175                                   \ /
                                                             X
                 ASCII Ribbon campaign against HTML E-Mail  / \
--------------------------------------------------------------------