8/12/2019 CDB Commit
2/3
2/27/2014 CDB Software, Inc.
http://www.cdbsoftware.com/whitepapers/cmnews-quarter4-2012.php
2/3
The Perils of Bachelor Programming Syndrome
Every DB2 application program should issue COMMIT statements
whenever the program modifies data. A
COMMIT externalizes all modifications made by the program since
it began or since the last COMMIT. I
refer to the practice of not coding COMMITs in DB2 programs as
Bachelor Programming Syndrome in
other words,fear of committing. A COMMIT ensures that all
modifications have been physically applied
to the DB2 log, thereby ensuring data integrity and
recoverability.
One factor impacting the need for a COMMIT strategy is the
amount of elapsed time required for the
program to complete. The greater the amount of time needed, the
more important it becomes to issue
COMMITs to reduce rollback time and reprocessing time in the
event of program failure.
Issuing COMMITs in an application program is important for three
reasons. First, if the program fails, all the
modifications are backed out to the last COMMIT point. This
process could take twice the time it took to
perform the modifications in the first place especially if you
are near the end of a program with no
COMMITs that performed hundreds or thousands of modification
operations.
Second, if you resubmit a failing program that issues no
COMMITs, the program must redo work
unnecessarily.
Third, programs bound using the repeatable read page locking
strategy or the RELEASE(COMMIT) table
space locking strategy hold their respective page and table
space locks until a COMMIT is issued. If no
COMMITs are issued during the program, locks are not released
until the auto-COMMIT when the program
completes, thereby negatively affecting concurrent access. This
can cause lock timeouts and lock escalation.
If your program is running for a long time and has issued no
COMMITs, your program is probably not going
to be the one to suffer. However, every other process attempting
to access the data that is locked by yourprogram will suffer. If
you regularly see a large number of -911 and -913 SQL return codes
in your DB2
subsystem, it is a safe bet that you have at least one
long-running program (maybe more) that needs to have
COMMIT logic added.
It is also good programming practice to issue periodic COMMITs
in long-running read-only programs. Even
though data is not being changed, DB2 acquires read locks
whenever data is accessed. A read lock can
block DB2 utility programs from operating successfully.
Therefore, failure to COMMIT, even in a read-only
program, can result in online utilities not being able to issue
a drain, and thereby not completing.
For these reasons, I recommend that you plan to issue COMMITs in
every batch DB2 program.
Contribution by Craig Mullins
Craig S. Mullins, president and principal consultant of Mullins
Consulting, Inc., is a data management
strategist, researcher, and consultant. He has nearly three
decades of experience in all facets of database
systems development and has worked with mainframe DB2 since V1.
You may know Craig from his popular
books: DB2 Developers Guide (with over 1500 pages of in-depth
technical information on DB2 for z/OS)
and Database Administration: The Complete Guide to Practices and
Procedures (the industrys only
comprehensive guide to heterogeneous database administration).
Craig can be reached via his website atwww.craigsmullins.com.
return to white papers
http://www.cdbsoftware.com/white-papers-and-articles.phphttp://www.craigsmullins.com/
