Re: MVC Architecture and transactions

Joe Pluta wrote:

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.

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.

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.

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.

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.

Like I said earlier, we couldn't recall the trucks that were out delivering product just because the rules changed this moment. And so it was mutually agreed that we would not revisit older orders in the interest of getting changes into the system sooner. We did in fact have a process that summarised the value (qty * price) of the line items affected by the condiment file update, so the head office had another data point as to whether they wanted to go back and generate new POs or not. Along with an inquiry that allowed the order desk to locate those orders... Commitment control wasn't *everything* in the solution set, but it was a very useful member.

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.

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