RE: framework question

Loyd,

Very well written.

One slight disagreement.
> 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.

Even if the crash happened in the last second, I don't believe OS/400 would
corrupt itself.  If the transaction hasn't been marked as clean, then it
will be recovered during the next IPL.  The OS would compare what was
written to what was supposed to be written, decide that the write was clean
and mark the journal accordingly.

Charles


> -----Original Message-----
> From: Loyd Goodbar [mailto:loyd@xxxxxxxxxxxxxx]
> Sent: Wednesday, July 07, 2004 6:37 PM
> To: Java Programming on and around the iSeries / AS400
> Subject: 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/
> 
> 
> 
> --
> This is the Java Programming on and around the iSeries / 
> AS400 (JAVA400-L) mailing list
> To post a message email: JAVA400-L@xxxxxxxxxxxx
> To subscribe, unsubscribe, or change list options,
> visit: http://lists.midrange.com/mailman/listinfo/java400-l
> or email: JAVA400-L-request@xxxxxxxxxxxx
> Before posting, please take a moment to review the archives
> at http://archive.midrange.com/java400-l.
>