Re: framework question -- JAVA400-L


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  / \
--------------------------------------------------------------------