From: Wilt, Charles
I don't disagree, but I prefer a "controled" hard halt.
One that doesn't leave my DB half updated, requiring me to not only fix
the error but recover the DB.
Exactly what situation do you foresee that will cause a hard halt? And what
are you going to do to fix it? Explain to me your procedures. For example,
you have someone on the Internet entering an order. Some moron locks a
master record using DFU. Rather than a hard halt with a record lock which
someone can respond to, perhaps getting the idiot off of the record and then
pushing the transaction through, you instead do what? Roll back the
transaction and send some sort of "we're sorry, but your order failed"
message to the user?
Or you're in the middle of an MRP generation, and you find a missing record.
What does commitment control buy you? You do what, just skip the offending
transaction and continue on with your MRP generation? How do you reapply
the transaction later? Do you suspense it? So now you need to add a
suspense file. Seems like this could get involved.
Then there's simple problem determination. How do you determine what caused
the error? Do you dump the whole program? I don't know, but I want the job
that fails unexpectedly to be halted so that I can debug it and find out
what exactly is going on. I want to do a STRSRVJOB and go in and identify
the exact cause of the problem.
I guess I just don't buy the whole "commitment control as error protection"
thing. I think you need to spend WAY more time making sure errors don't get
into production, because if they do commitment control doesn't buy you much
except maybe some unwarranted peace of mind.
The thing is anyplace the validation and transaction are two separate
steps could be an issue, just
two users doing the same thing or different things that happen to hit the
same records milliseconds apart.
I don't understand this at all. There are two types of updates: data
replace and data accumulation. You either modify a field or you accumulate
an amount. Which of these is broken if two jobs hit the same files? If two
people modify an address, one will win. But that's a classic problem that
isn't handled by commitment control; it requires before and after images or
modification counters.
Data accumulation is another issue. Order doesn't matter in those cases,
which is why I'm asking for a specific situation. If I add a hundred
dollars to an account and you subtract fifty, it doesn't matter what order
we do them in. The amounts will still be added.
See, I'm not trying to say commitment control is bad, I just want to
understand exact situations where it's required.
All I'm saying is that commitment control provides a standard way to
handle things you might have had
to manually code before. As a bonus, the ACID characteristics of an
application designed to use
commitment control would be better than one where all the ACID
characteristics are hand coded.
See, this is the interesting bit. Commitment control allows you to back out
changes to your database in the case of an error in mid-transaction.
Personally, I don't have many situations where I do that. No master file
maintenance program does that. No simple transaction posting program does
that. There may be some complex transactions that could use this sort of
failsafe, but again, I can't think of any. I mean, if I update one side of
a general ledger, I don't put in code to check for an I/O error on the
second half and then go back and undo the first change. I just don't.
That's a lot of extra code. Am I a bad programmer? I don't think so,
because chances are an I/O error is going to cause a lot more problems than
just this simple ledge update.
I know I'm playing devil's advocate here, but I have yet to see one specific
case that requires commitment control that doesn't involve either some sort
of egregious system error such as a disk I/O error or some fantastically bad
programming technique such as holding long locks or allowing unfettered
access to the database.
The ONLY possibility I see is someone doing really fundamental maintenance
to master files during transaction processing. Yes, that can happen, but
please tell me a specific circumstance that this will happen and bang up
your business - and that commitment control would fix. And I'm not asking
to be contrary, I would like to be able to define a class of transactions
that exemplify the need for CC!
Correct me if I'm wrong, but I think your one of your biggest arguments
against commitment control is
the cost. Namly the DASD space required for journaling and time required
to manage it.
Disk cost, setup cost, management cost. I haven't yet seen any real numbers
on performance, either. When you have 20,000 users all banging on the same
master records, and you increase the lock time on those records (which you
have to, because they're no longer locked for just the update of the master
record, but also all other master records and detail records in the
transaction), then there has to be SOME hit. The question is how much of a
hit? Nobody here knows.
As other have
pointed out, system managed receivers takes most of that pain away. In
addition, you've got the the
MINENTDTA and FIXLENDTA parms to help lower the size of journal entries.
Lastly, how many
applications do you have that don't use journaling, but do have various
output only audit files to
track who did what when. Sounds like a roll-your-own journal to me
<smile>.
If you're using journals as audit files, you can't let the system delete
them. Now you have multiple classes of journals, and heaven help you if you
put the wrong file in the wrong journal.
Again, I'm just saying.
Anyway, I don't think I'll change anyone's mind who has already decided to
use commitment control. And CC is a good thing in certain situations, maybe
even lots of situations. I just want to be sure that anyone who is thinking
about adopting CC really considers all the issues.
Joe
midrange.com
