On Jul 24, 2009, at 4:58 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 4:45 PM, Nikunj R. Mehta<[email protected]
> wrote:
No. The transaction is not closed on GC, it is closed when the last
statement that is part of the transaction completes. So holding a
reference to the tx variable does nothing one way or the other. The
only way to hang the transaction open would be to execute statements
over and over.
A transaction is not complete until I either commit or rollback the
transaction, which I can choose to do as late as I want to, e.g., at
window.onclose. Therefore locks on the database will not be
released for as
long as the application wants to hold on to the transaction.
I don't think that this is true, at least in the Database interface:
http://dev.w3.org/html5/webdatabase/#asynchronous-database-api
There is no explicit commit() method. The commit happens implicitly
after all queued statements have been executed successfully.
The spec is also silent about what happens if I put a wait by making
another asynchronous call inside my transaction callback logic. By
inference, this would be allowed since all statements are executed
inside callbacks, so why distinguish between transaction and other
(non-SQLTransactionErrorCallback) types of callbacks.
The processing model in 4.3.2 simply says that the SQL statements are
queued up. It is unclear what if anything happens if the database runs
out of statements to execute if the transaction logic takes time to
add another statement to the queue before the database decides to
commit. Am I wrong or is this an ambiguous, but correct interpretation?
Those who are worried about throwing complexity of transaction
recovery on Web programmers should perhaps also be worried about the
insane complexity of asynchronous transaction programming, that no one
in the world should have to learn. The mainstream database developers
don't have to deal with that. Why should poor Web programmers have to
suffer this?
Moreover, with an asynchronous database the spec doesn't allow an
application to rollback a transaction, should certain application
logic require that. This is yet another case of creating a storage API
that is different from traditional database developers.
There seems to be a pattern of ignoring good API practices when
interacting with a database and it appears intentional. Am I wrong in
my interpretation?
It does appear that it is possible to hold a transaction open all day
with the DatabaseSync interface
(http://dev.w3.org/html5/webdatabase/#databasesync). Specifically the
SQLTransactionSync method has commit/rollback methods. The
DatabaseSync interface was added after I worked on this, so I can't
say why it doesn't use callbacks.
In any case, I was talking about the async flavor which is what my
example code referred to. Do you agree it is not possible to hang
transactions open from Database
(http://dev.w3.org/html5/webdatabase/#database)? If not, what am I
missing?
I can't agree simply because the spec says nothing about it. In fact,
if anything the rest of the spec text around asynchronous processing
suggests that it is possible to hang transactions indefinitely.
Nikunj
http://o-micron.blogspot.com
