Snippet below captures the original discussion, also in [1]. Short version is that currently the spec indicates that transactions will commit once user code unwinds and there are no pending operations for the transaction. The problem with this approach is that code unwinding because of an uncaught exception will silently commit the transaction. We should either require a commit() call (and abort by default) or somehow avoid committing on error cases. My preference is to require a commit() call, but that causes trouble with some patterns we'd have to re-think (e.g. db.objectStores("foo").put({...}) ).

>> >>> This will likely be extra bad for transactions where no write
>> >>> operations are done. In this case failure to call a 'commit()'
>> >>> function won't result in any broken behavior. The transaction will
>> >>> just sit open for a long time and eventually "rolled back", though
>> >>> since no changes were done, the rollback is transparent, and the only
>> >>> noticeable effect is that the application halts for a while while the
>> >>> transaction is waiting to time out.
>> >>>
>> >>> I should add that the WebSQLDatabase uses automatically committing
>> >>> transactions very similar to what we're proposing, and it seems to
>> >>> have worked fine there.
>> >
>> > I find this a bit scary, although it could be that I'm permanently tainted with traditional database stuff. Typical databases follow a presumed abort protocol, where if your code is interrupted by an exception, a process crash or whatever, you can always assume transactions will be rolled back if you didn't reach an explicit call to commit. The implicit commit here takes that away, and I'm not sure how safe that is.
>> >
>> > For example, if I don't have proper exception handling in place, an illegal call to some other non-indexeddb related API may throw an exception causing the whole thing to unwind, at which point nothing will be pending to do in the database and thus the currently active transaction will be committed.
>> >
>> > Using the same line of thought we used for READ_ONLY, forgetting to call commit() is easy to detect the first time you try out your code. Your changes will simply not stick. It's not as clear as the READ_ONLY example because there is no opportunity to throw an explicit exception with an explanation, but the data not being around will certainly prompt developers to look for the issue :)

>> Ah, I see where we are differing in thinking. My main concern has been
>> that of rollbacks, and associated dataloss, in the non-error case. For
>> example people forget to call commit() in some branch of their code,
>> thus causing dataloss when the transaction is rolled back.
>>
>> Your concern seems to be that of lack of rollback in the error case,
>> for example when an exception is thrown and not caught somewhere in
>> the code. In this case you'd want to have the transaction rolled back.
>>
>> One way to handle this is to try to detect unhandled errors and
>> implicitly roll back the transaction. Two situations where we could do
>> this is:
>> 1. When an 'error' event is fired, but where .preventDefault() has is
>> not called by any handler. The result is that if an error is ever
>> fired, but no one explicitly handles it, we roll back the transaction.
>> See also below.
>> 2. When a success handler is called, but the handler throws an exception.
>>
>> The second is a bit of a problem from a spec point of view. I'm not
>> sure it is allowed by the DOM Events spec, or by all existing DOM
>> Events implementations. I do still think we can pull it off though.
>> This is something I've been thinking about raising for a while, but I
>> wanted to nail down the raised issues first.
>>
>> Would you feel more comfortable with implicit commits if we did the above?

It does make it better, although this seems to introduce quite moving parts to the process. I still think an explicit commit() would be better, but I'm open to explore more options.

[1] http://lists.w3.org/Archives/Public/public-webapps/2010JulSep/0231.html