I never actually implemented it - it was more of a thought experiment. Also it was an interactive environment, so the idea was that I could simply check the value of the LastUpdated field when I went to perform an update, and if it wasn't the same as it was _before_ the update, then I'd warn the user and present them with the differing values, at which point they could manually resolve any conflicts.
In your case I was thinking that you'd save a memento, including the LastUpdated, and then if you needed to roll back you could replace the values with the memento *if* the LastUpdated remained the same. But it sounds like that wouldn't be iron-clad enough for you. I might have to concur that you're screwed. :-( Sometimes we simply have to tell the powers that be that "it cannot be done". It sounds like you don't have enough control to actually accomplish what you're being asked to do. Attempting to do it might introduce more risks that your stakeholders are willing to take. On Tue, Jan 27, 2009 at 10:25 PM, Barry Beattie <[email protected]> wrote: > > @Bob, I forgot to ask when I replied ... how effective did you find > that solution? any gotcha's or points to consider? > > > >>> Do the records in the tables contain >>> a column that is updated on every transaction? Like a >>> LastUpdateTimestamp, or unique id? And if they do, is that info >>> available to you via the webservice interface? >> >> I think I can see what you're getting at: use the timestamp to check >> for data concurrency of the records being edited and tie that in to a >> memento pattern. >> >> I thing that's going to beat me is how to handle a network outage part >> of the way thru the writing process - where some entities get updated >> but others are left hanging/untouched (when they should be changed to >> match the others). The memento pattern may be able to hold onto the >> "state" of all the entities, but there's no way to reach out to them >> to roll them back if the network is down. In the case of a network >> outage, I'd really need the whole lot to fail so it can be re-run, >> rather than being half pregnant... >> >> outage includes brown-outs and high traffic causing time-outs. >> > > > > -- Bob Silverberg www.silverwareconsulting.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CFCDev" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cfcdev?hl=en -~----------~----~----~----~------~----~------~--~---
