Hi,
I disagree, my former company was vendor, too and everything was journaled
and commitment control was heavily used. To switch off journaling or
commitment control was not possible, because we wanted to make sure that a
transaction is either completed or completely resettet.
What we did, if a client did not want to "waste" disc space, we reduced the
journal receiver size and did an automatic delete of the receiver as soon as
it was finished and the next one active. In this way we could guarantee that
all transactions were completed, but a complete restore or reset out of the
journal was not possible, but THIS is IMHO customer's choice or risk.
Mit freundlichen Grüßen / Best regards
Birgitta Hauser
"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"
-----Ursprüngliche Nachricht-----
Von: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von Simon Coulter
Gesendet: Friday, 21. August 2009 00:40
An: Midrange Systems Technical Discussion
Betreff: Re: Commitment Control (was: Modernizing applications (was:
Explaining single level store tonon ipeople))
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.
Regards,
Simon Coulter.
--------------------------------------------------------------------
FlyByNight Software OS/400, i5/OS Technical Specialists
http://www.flybynight.com.au/
Phone: +61 2 6657 8251 Mobile: +61 0411 091 400 /"\
Fax: +61 2 6657 8251 \ /
X
ASCII Ribbon campaign against HTML E-Mail / \
--------------------------------------------------------------------
midrange.com
