- From: Brady Eidson <beidson@apple.com>
- Date: Wed, 17 Oct 2007 12:46:40 -0700
On Oct 17, 2007, at 11:49 AM, Maciej Stachowiak wrote: >>> Downsides to this approach: >>> >>> - You could only have one transaction in flight at once, so you'd >>> have to do scheduling in the app code if a transaction-starting UI >>> operation happens while you already have a transaction in >>> progress. Otherwise multiple transactions would get scrambled. (Or >>> else the API layer could parse your statements and understand when >>> you have opened a transaction to still implicitly assign >>> statements in your callbacks to the transaction, but I am not sure >>> this is a simplification overall.) >>> >>> - An author mistake (like doing something that causes an exception >>> in the callback) means a stuck lock, quite possibly ruining the >>> whole session. >> >> I agree these are potential downfalls, but ones that already exist >> with the current spec. We have the implicit transaction already, >> so a performance-minded developer starting their own transaction >> might already trigger this scenario > > I don't think you would typically need to use BEGIN, COMMIT or > ROLLBACK with the current API, but perhaps the spec should define > what happens if you do. In any case, using the easiest path to > transactions would not have either of these pitfalls. There is a problem that has been alluded too in this thread but not explicitly called out. For all the tracking of implicit transactions, having "active thread global transactions" in an executeSql() chain, and have changeVersion() wait until all transactions are closed... how do we handle web developers who start their own transactions? The user agent can keep track the implicit transactions it manages, but a developer throwing a rogue "BEGIN TRANSACTION;" into the mix can throw this all off. Especially in the context of changeVersion() which is supposed to be an explicit guarantee of the version change. Is there some detail/assumption that has been made that I am missing which makes this a non-issue? ~Brady
Received on Wednesday, 17 October 2007 12:46:40 UTC