From: Buck
When the customer agreement is first implemented, there were many, many
changes to the condiment file. Live, during the day, whilst orders were
being phoned in. We found that there were enough orders going out wrong
that we had to verify again whilst we were updating. This isn't
difficult, it's
dow
rrn chain sfl
item chain condiment
if condiment and non-condiment flag is set, error out
if non-condiment and condiment flag is set, error out
exsr update
enddo
CC comes in when you've validated item 1 and done UPDATE. Then you
attempt to validate item 2 and it fails. ROLLBACK then brings the
entire transaction back to a known state and the order desk can tell the
purchasing agent that ketchup is a condiment.
You missed my point. You do the "if condiment" check for the ketchup line
while it is not a condiment and you set the non-condiment flag. Prior to
reading the next line, head office calls and says "ketchup is a condiment".
Next line is read, it's a non-condiment, you proceed with the order.
However, you have an order where you have a condiment and a non-condiment.
Unless you add a complete second check after the order is entirely
processed, you can't possibly catch every error.
My point is that there is a cutoff time where the change is not honored, and
commitment control doesn't fix it. All commitment control does is allow you
to rollback the order that just happened to be between validation and
posting, but not yet in the middle of posting. I can't see this as ever
being more than one order per business rule change, and even then only once
in a blue moon.
(Side topic: You say this as though management expects such a change to
happen instantaneously and completely. What about any outstanding
orders
prior to this that have ketchup going to the wrong warehouse? Did you
fix
those? I bet not. So this one order that was in process simply follows
all
the rules that were in place MILLISECONDS prior, just like all the other
orders that day.)
The discussion was had, and our QoS agreement was modified to note that
items changing status had to be invoiced properly after the item change
timestamp. We couldn't control what was already enroute on the trucks,
either.
Yup. And that should also handle the one order above.
A CHAIN and two compares isn't a lot of effort to secure millions of
dollars worth of sales. CC lets us undo all the updates scattered
across ye-gods files and lets the order desk segregate out either the
condiments or the non-condiments as the purchasing agent required.
Again, I have a hard time with this, because you still have orders with
condiments and non-condiments. Any order outstanding before the change is
potentially bad, and that includes the ONE SINGLE ORDER that was actually in
process at the exact microsecond of the change.
The order that was being processed at the time is the same as the one that
was taken five seconds earlier before the change, and requires the same
processing. Commitment control doesn't fix this.
> Yes, commitment control has its uses, but facilitating the change of
> business rules isn't one of them, I don't think.
Fair enough. What uses do you use commitment control for?
I don't use commitment control <grin>. I think that's my point. I think
that people use commitment control for a lot of wrong reasons, and then when
you look closely, the CC emperor is walking around naked.
I suppose I could envision a situation where an external asynchronous event
could change a database flag that would affect a transaction between
validation and posting. But again, I'd have problems that any transaction
posted immediately previous would be following the old rules. It seems to
me that anybody changing business rules would have to have a business
procedure in place to deal with transactions posted prior to the changeover.
That's just basic business sense. Changing a rule doesn't magically fix
everything that's already been done.
So let's try the situation Nathan talks about, where I need to update a
bunch of similar records simultaneously and another business event could
occur during the processing causing the current transaction to become
invalid. Two ways to prevent that: stop external events, or rollback when
an external event causes an error. Commitment control seems to provide a
good vehicle there, because it will lock all the records and thus prevent
external events, and also provide a mechanism for rolling back.
In the old days, we did this with lock flags, and I think CC is probably a
better solution. But this is the only class of operations I can see, and
very few things really fall into this category. Accumulators such as
general ledgers don't count, because the changes to them can't be
invalidated by a normal external event. Banking transactions, and possibly
(but only possibly) inventory-based transactions might fall into this realm,
but the vast majority of simple CRUD transactions do not.
You know, in the case of banking transactions, I would have written the
system in such a way that prior to posting a transaction, I would ALLOCATE
the funds. Allocated funds would be unavailable to other transactions. The
only valid transaction would be one that could allocate all the funds. Once
I had indeed allocated all the funds in all the locations for a given
transaction, only then would I be able to post the transaction. And during
that time, no other transaction could allocate those funds and thus
invalidate my transaction. Seems a pretty simple way to avoid all those
nasty complications. But hey, I don't live in the real world <grin>.
Funny though, that bank programmers wouldn't have thought that little quirk
through and are instead evidently writing systems where one transaction can
invalidate another one.
Anyway, enough already. As long as people are now thinking about this, and
not just taking it on faith that "commitment control is good" then my job
here is done. <smile>
Joe
midrange.com
