- From: Ian Hickson <ian@hixie.ch>
- Date: Fri, 26 Oct 2007 22:51:51 +0000 (UTC)
On Thu, 25 Oct 2007, Brady Eidson wrote: > > For major steps during processing of a transaction, if that step fails > the SQLTransactionErrorCallback is invoked. > > Additionally, for each statement processed within a transaction, success > and failure in executing that statement both result in a callback - > SQLStatementCallback and SQLStatementErrorCallback respectively. > > With the above mechanisms, there is a lot of solid notification to the > script about progress of a transaction. There seems to be a flaring > hole, however. > > Step 9 of the transaction steps stipulates that if the transaction fails > to commit, the script will get an SQLTransactionErrorCallback indicating > this failure. However, there is no final callback indicating *success* > of the commit. > > In the case of a general transaction used for a chain of executeSql > calls, the script will have gotten a callback for each statement as it > succeeds and therefore might assume the transaction will succeed. > However, they don't know *when* is has succeeded. > > In the case of the transaction wrapped by a changeVersion() call, the > script will definitely know when the changeVersion() fails, but will not > know at what point in time the changeVersion() has finished and the data > is all committed to disk. > > I can see a script wanting to know when a transaction is actually 100% > complete and committed before moving on to the next task. I just don't > know how important it is, and wanted to bring this point up for > discussion. We can add a third callback to changeVersion() and transaction(). I can't see any other way to solve it. What do people think? Too heavy-weight, or ok? I'm ok with doing it if people want it. -- Ian Hickson U+1047E )\._.,--....,'``. fL http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Received on Friday, 26 October 2007 15:51:51 UTC