Re: framework question

For a single file update, there's probably little incentive for commitment
control. For multi-file updates, it's more crucial.

Journal recovery automatically looks at transaction boundaries if transactions
are used. Uncommitted (unfinished) transactions are rolled back from the
database automatically, no user intervention required. There is some work in
redoing failed transactions, but it is offset by having a consistent database
(from a logical view); there are no half-updated transactions.

I haven't looked into the guts of how OS/400 does journaling and recovery, but
I suspect the process looks like this:
* request to write to database
* journal accepts request
* journal updates database, waits for success from database
* journal gets success from database, marks request as clean

In this scenario, the only time the database could corrupt itself is the
instant the last step is executed. If any of the other steps fail, the request
is rolled back. Transactions would follow a similar path, but have additional
steps to maintain transactional integrity.

While we are talking about CC, not using transactions violates the RDBMS
design principle of ACID (atomic, consistent, isolated, durable). In a
multi-file update (a new PO for example), write the header record then the
detail record. Without transactions, as soon as the header record is written
to the database, it is visible to outside processes when it shouldn't be; it
should be visible only after the detail records are written. This violates the
atomic and isolated portions of ACID (the transaction is written piecemeal and
not as a whole, and the database changes are not isolated from the world
during the update). It could be argued that writing a single detail record is
a transaction, but that would be a fallicy; in a true RDBMS with RI would
disallow new detail records without a header (orphaned child records), as well
as a header record with no detail (widowed parent record).

With in-use flags, other processes (think Query) have an instant in which they
can see the header record without detail records, or partially updated records
in multiple files. Atomic transactions ensure the "view" of the database is
updated on the transaction boundary, not on each record update.

What should happen is this:
1. Start transaction. From here forward, other processes don't see what's
going on.
2. Write header record.
3. Write detail record.
4. Write detail record.
5. Commit transaction. The database writes the changes to the database as a
single unit. Any failure (RI violation, disk full, loss of power) keeps the
transaction in a "dirty" state and is not successful. Depending on the
failure, the application can notify the user or take corrective action.
6. Other processes can see the new records.

In steps 2-5, you really DON'T want other programs to see these updates since
they're not complete.

We've all been going on about whether CC is truly useful (or not). Not every
AS/400 application needs full ACID compliance. But mainstay applications
(inventory, manufacturing, financials, payroll) IMO would greatly benefit from
letting DB2 do what it's good at, and that's managing the database.

Loyd

On Tue, 6 Jul 2004 18:03:47 -0600, "Nathan Andelin"
<nandel@xxxxxxxxxxxxxxxxxxx> wrote:

>Lloyd,
>
>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?  
>
>Nathan.

--  
"Don't need therpay, all better now!" --Jaye, Wonderfalls
loyd@xxxxxxxxxxxxxx  ICQ#504581  http://www.blackrobes.net/