RE: MVC Architecture and transactions

From: Buck

As long as the update timestamp is before the change timestamp we
satisfy our QoS. In an 'always-on' world, it's becoming more difficult
to put a hold on processing X so that you can process Y. We originally
wanted to do just that: we asked that condiment file changes be batched
up and applied after normal business hours, but the customer requested
real-time updates. It follows that they can inquire what is what during
real time as well.

Buck, you're missing my point again! That order that you rolled back should
be posted with a timestamp that you fetched at the beginning the update, and
then the order would have a timestamp prior to the update of the master
file.

It just seems to me that you've unnecessarily convoluted this. The order
that was in process before the change was made should be considered prior to
the change, and should be handled like any other order prior to the change.
The ONLY order that could possibly be affected by your design is one in
which the first record is updated milliseconds BEFORE the change to the
master file and the last record is updated milliseconds after. Is this
really worth all this trouble? It seems to me that this is really an order
that LOGICALLY was posted BEFORE the change.

Yes, 'all' CC does is to allow many files to be partially updated (i.e.
existing code remains unchanged) and then restored to their previous
state while letting other processes update those files exactly
simultaneously. That's quite a good bit of functionality embodied in a
fairly simple implementation.

I'm not arguing the functionality of CC. It has great functionality. It's
just usually not needed. You still haven't provided me a reason why you had
to use CC for your situation. The order that was being processed when the
change occurred should have been timestamped prior to the change, and thus
been processed with every other prior order. No CC, no additional coding,
nothing.

No. Our QoS agreement says that orders updated before ketchup became a
condiment are OK. This isn't a batch system, where orders allocate
inventory in a holding pen and updated at the end of the day. It's
live, online processing, which means that the RI changed while orders
were phoned in. It was expected, understood and agreed that earlier
orders would not be subject to later rules changes.

Yup. The order that was in process of being updated before the change
occurred is "before". If the first update occurred before the change, then
the order is considered "before". (Who said anything about batch?)

Well there's the explanation of our differing point of view. Commitment
control saved me untold grief trying to roll my own solution. If I'd
realised you hadn't used commitment control I'd have probably used
different words to explain better where CC fit into an existing process
with very little disruption.

Buck, I have used commitment control and I understand it. I've also written
my own rollback routines. My point is that I don't see much use for either.
I didn't say NO use, and I didn't say CC has no place. I just said that a
lot of the reasons used to justify CC don't make sense to me. If you use
the first update as the timestamp for the order, you wouldn't have to use
CC. You might have a lot of other great reasons to use CC, but changing the
business rules isn't one of them.

Joe