Re: Commitment Control (was: Modernizing applications (was: Explaining single level store tonon ipeople))

Charles,

Many years ago I attended a Common session conducted by the then head of
development for journalling in Rochester. He quite simply said only journal
the files you care about.

Your points are 100% on target. Over the past 20 years I have had my
programmers change their programming style in batch as well as interactive
applications to process sets of data in batch and commit after processing
each successful set of records (like batch orders with customer, order, line
item details) and commit after an order is processed. This would include
something like a processing flag in the order record that would get updated
also. Bottom line is that if a failure occurs you just re-run the job, it
picks up with the next unprocessed record and continues. You always maintain
financial integrity. A failure causes an automatic rollback and all
uncommitted changes or records get rolled back.

Commitment control and set processing should occur in all interactive, web,
or batch processing. It will provide you with greatly improved data
integrity in your database and simplify error recovery greatly.

Your point on a user canceling their order and having to write logic to back
out updates in several places is a really excellent one. Why write the code
when you simply use a rollback.



On Thu, Aug 20, 2009 at 11:23 AM, Charles Wilt <charles.wilt@xxxxxxxxx>wrote:

Your understanding is wrong.

What happens if the program is ended via user action, system crash,
power failure, ect... between the write to one table and the update of
the other?

You've got two choices
1) Use commitment control
2) Add lots of extra code into your application for recovery.

In this day and age, why would you write develop and application
without commitment control?

Charles

On Thu, Aug 20, 2009 at 11:39 AM, Nathan Andelin<nandelin@xxxxxxxxx>
wrote:

My understanding and position now is that in cases where you write a

record to one table and update another by a single transaction, you can for
all practical purposes, guarantee Atomicity, Consistency, Isolation, &
Durability, with RPG RLA by first getting a lock on the row you're updating,
write the transaction, check for a write error, then conditionally update
the locked record if no error occurs on the write.

On the other hand, if you are relegated to only using SQL ...

-Nathan.

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives
at http://archive.midrange.com/midrange-l.