On 21/08/2009, at 7:53 AM, Nathan Andelin wrote:

I already indicated that I plan on using commitment control with journaling for GL Journal Entry. It seems to me that one of the advantages of IBM i is that business can consider the circumstances, decide which tables are worth journaling, which transactions must commit (or rollback), or whether journaling and commitment control may be obsessive. Some DBMS vendors don't offer a choice.

For what it's worth:

Whether commitment-control (and therefore journalling) is used in an application should be a customer choice--not a vendor choice.

Vendor applications should be written to support commitment control. Whether it's in effect can be determined at run-time. Code is written to wrap COMMIT and ROLLBACK instructions in a test for commitment- control being active. The customer sets a configuration option to activate or disable as required.

Regardless of how unlikely you view a catastrophic failure occurring between related database modifications (i.e., a logical transaction), if you perform discrete operations without commitment control then a window exists in which one or more of those operations may not be completed. Your program will likely also be unaware of that failure because it's dead too. Should such a failure occur you have an integrity problem in your database.

You either have to build in a restart capability to your application (usually via a transaction span record) or rely on manual recovery techniques. Commitment control can avoid this situation by ensuring database integrity. Application-level restart then becomes a nice-to- have feature.

Adding support for commitment control to an application takes very little extra work--really just a matter of defining logical transaction boundaries. The customer can then decide whether the operational costs of disk space and CPU are worth the increased reliability of the application.

Extra disk space used by journalling for commitment control can be reduced by setting appropriate journal attributes. Extra CPU is usually not an issue--especially on recent hardware.

Simon Coulter.
FlyByNight Software OS/400, i5/OS Technical Specialists

Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
ASCII Ribbon campaign against HTML E-Mail / \

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2019 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].