RE: MVC Architecture and transactions

From: Buck

I have used commitment control in a high transaction rate environment,
and I have found significant value beyond maintaining RI during a crash.

And I think I mentioned that CC has uses outside of RI. My point is that
not EVERYBODY needs CC.

I think that it is important to recognise that there is probably more
than one update program per file, and they _all_ need to be written
'correctly,' not just the one under consideration at the moment.

Yes, I think I mentioned that as well. I think in my example I talked about
updating a half dozen files simultaneously, which would be a fairly normal
BPCS transaction.

'Correctly' has many connotations, including the ability of Process 2 to
not be able to delete an item master record that Process 1 has just
validated an order against, but not written to disk yet.

Well, this is an interesting issue. But how often are you deleting item
master records? Are you really regularly in situations that cause you to
delete item master records while order entry is going on? I'm not
downplaying the situation, but if you're taking orders for items that are
being deleted, you have much larger process issues. In that case,
commitment control is actually covering up procedural problems.

Anyway, I want to be clear: I don't think CC is "bad" or even "never
appropriate". I rarely consider various programming techniques to be "bad"
or "good" in and of themselves, I just caution the use of technology where
it isn't warranted.

All programming decisions are first and foremost business decisions.

Joe