RE: MVC Architecture and transactions

From: Buck

The purchasing agent calls you up and places an order. Salt, pepper,
cups, ketchup packets and pencils. Your order entry catches the cups,
ketchup and pencils and your order desk tells the agent that you need a
new order for that stuff.

The purchasing agent does her magic to generate a new, proper PO and you
cause the salt and pepper order to update/process. The purchasing agent
then gives you the new order of ketchup, cups and pencils. Your order
entry validates that all those items are non-condiments. While doing
that, the head office calls in and adds ketchup packets to the list of
condiments. They're talking to a different person, in another office,
completely unaware that one of the purchasing agents is giving you an
order at this moment.

None of this has anything to do with commitment control, right? You
shouldn't be actually posting the order unless you do another validation.
So the real issue is that, once the purchasing agent hits the submit button,
there is a cycle where you validate the order then immediately post it. It
is this tiny window where a master file change (in effect, a serious change
in business rules) might cause a prevalidated order to be posted
incorrectly.

(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.)

So. Between validation (which passed) and update, the underlying RI
situation has changed. If your order entry program simply updates the
order without checking again, the customer will get an improper order,
delivery and invoice. Bad mojo, so you of course have validation in the
update cycle too. But there is still a window between CHAIN, validate
and UPDATE where the underlying RI situation can change as part of a
proper, normal process.

I was with you right until here. Yes, I understand that it's technically
possible that a master file update occurred here, between the validation and
the update.

But what does commitment control buy you in this case? Unless you run the
validation BEFORE the order, post the order, and then run the validation
again AFTER the order, rolling it back if it fails, then you're not going to
catch this issue. Because what if the change hits during the posting
process, and you've already posted the ketchup, but the salt hasn't been
posted yet? Then you have condiments going to two different warehouses,
right? So you really have to re-validate the entire order after it has been
posted but before it has been committed, right?

And if you're adding a second validation pass just to catch possible head
office changes that occurred during the past 30 milliseconds, then you
really are adding a lot of overhead to your process, and I don't think
commitment control is really the way to handle it.

Most RPG programmers get away with not worrying about that window
because it's pretty small, and their transaction rate isn't high enough
to statistically expect an RI change occurring within that window. But
once you've had a multi-million-dollar customer chew you out for not
keeping orders/deliveries/invoices straight, you have a tendency to
avoid future problems of that sort.

No, I suppose commitment control isn't for every situation, but this was
a real situation. It was pure RPG (no SQL) and it was way simpler to
implement than any home-grown alternative.

Still not seeing it, Buck. To me, the right way to handle major business
rules changes such as this is to write a program that checks all outstanding
orders to make sure they match the new business rules, and then provide an
exception report to handle them. This would catch all windows.

Yes, commitment control has its uses, but facilitating the change of
business rules isn't one of them, I don't think.

Joe