| [higgins-dev] IdAS update option 3.a commit |
|
Valery,
<splitting into smaller topics>
I think we're possibly thinking of the semantics of IContext.commit in different ways.
My intent was this: The user performs a number of update operations, each signifying that nothing should affect the backing store until commit is called. The CP should not begin apply these updates to it's backing data store in a way that will cause the store to ever be in an invalid state. The CP could simply store the updates in memory, or it could (if the backing store allows) begin a transaction which will be rolled back in case of the problems you mention.
If the CP can't temporarily hold the updates, and if the backing data store can't support the transaction, then it should fail the update operation(s) which request to be delayed until commit is called.
If a CP supports transactions, I don't think it should be capable of failing in the ways that you mention. If it did, it adds a burden to the user -- meaning the user would have to keep track of whether a transaction failed, then decide whether to back it out or try to continue (and if continuing, I'm not sure how it would know which parts failed).
So, in other words, IContext.commit either fully succeeds or fully fails, it never half-commits.
Jim
>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/16/07 3:14 PM >>> Jim, See in-line. -- Thanks, Valery Monday, April 16, 2007, 7:15:27 PM, you wrote: > >>>> Jim Sermersheim 4/16/07 10:10 AM >>> > >>>> Valery Kokhan <vkokhan@xxxxxxxxxxxxxx> 4/15/07 5:12 PM >>> >>Right now I'd prefer option 3 because I'm a little bit confused with >>the option 3.a. However I have to notice that if we introduce >>transactional support like IContext.commit() we should also provide a >>way like IContext.rollback() to restore local context state if >>transaction fails for some reason. > > IContext.commit("Atomic") does just this. The semantics are that > if the transaction fails for some reason, all changes are rolled back (not committed). > But the local state of the context remains changed. In general I see two cases why some transaction may fails - one due to device failure and another due to invalid data in the local state of the context. In the first case a consumer may choose just to commit again while in the second it is much easier to restore context local state and start to update it again then to find out and resolve real reason of the failure. That is why I think we need a method like rollback(). |