RE: framework question

> -----Original Message-----
> From: Joe Pluta [mailto:joepluta@xxxxxxxxxxxxxxxxx]
> Sent: Monday, July 05, 2004 5:34 PM
> To: 'Java Programming on and around the iSeries / AS400'
> Subject: RE: framework question
> 
> 
> > Other reasons for needing commitment control include things like
> record
> > contention and  fat fingered operators which are far more likely.
> 
> I guess I'm slow here.  Can you provide some real-world examples of
> where commitment control helps in either of these instances?
> 

Joe, it's pretty simply really.  You've got an application that updates
multiple records in multiple files.
What happens if for whatever reason you can't update a particular record you
need to.  Perhaps the record has been locked by someone else, or deleted,
located on a IASP that just went offline, or whatever.  You can't just
ignore this, as you'd be leaving the DB in an inconsistent state with the
transaction you were working on partially completed.

Now, you've got a good programmer who's got all the error checking needed in
the program.  Perhaps the program can pause then try again.  But perhaps
you'll need to undo the changes you've already made.  Without commitment
control you can't guarantee that is possible.  You could have your own
pseudo-commitment control by logging the changes, ect. you've made but you
still can't guarantee you can do the rollback properly.  If for no other
reason than you can't prevent another program from modifying that data
between your write and trying to do your own rollback.

Not that the programmer isn't good enough.  It simply can't be done from the
outside of the DB.  You mentioned RPG's atomic READ & LOCK.  It's not really
RPG doing that, it's the DB.  All commitment control is an atomic READ/WRITE
across multiple files and records.  Either the entire set of records gets
written out or none of them do.  Again the process is and must be handled by
the DB code, an external program simply doesn't have anyway to do it
atomically.


> 
> 
> And exactly how would the state get inconsistent short of programmer
> error?  And if there is a programmer error, how does 
> commitment control
> fix that?  This is why you fire programmers who don't program 
> properly.
> If this same bad programmer simply forgets to write the 
> record or writes
> bad data, then commitment control buys you nothing.  In fact, 
> it's much
> more likely that this is what will happen as opposed to an abend.
> 
> Let's be clear: PROGRAMMER ERROR IS NOT A VALID REASON FOR COMMITMENT
> CONTROL.  If anything, it becomes a crutch that lazy 
> programmers rely on
> as opposed to actually testing their code.
> 

Again it's not a question of programmer error with a program abending.  It's
simply a tool to allow the programmer to handle errors that otherwise
couldn't be handled without leaving the DB in an inconsistent state.


> 
> 
> Is it worth doubling or tripling your disk requirements and 
> slowing down
> your system as opposed to training an operator or fixing a program?
> 
> Joe
> 

Not sure where you're pulling those numbers from Joe, there's no way you'd
need double or triple your disk requirement to support journaling and
commitment control.  Unless you were planning on leaving the journal
receivers out there permanently or had a very poorly designed application
doing something like writing out updates one field at a time.

Granted DASD usage is an issue.  But with the DASD prices coming down and
the new options to minimize the data written to the journal it's not the
issue it used to be.

Performance wise, again could be an issue if you've got 100K transactions an
hour.  But again, there have been improvements made in this area.  As I
recall the case study mostly on behalf of a huge financial firm doing 100's
of thousand transactions an hour.

Heck, one of the easiest performance improvements is to simply place your
journal receivers in a separate ASP.  As a bonus, it improves disaster
recovery too.


If you're still writing critical applications without commitment control,
then you're doing your customers a dis-service.  Can you write a multi-user
application without commitment control?  Sure, but it would be a better
application if you used it.  I'd urge you to look into what it can do for
you in detail and how to take advantage of it.



Charles