Re: [WebStorage] Concerns on spec section 'Processing Model'

On Jul 24, 2009, at 4:58 PM, Aaron Boodman wrote:

> On Fri, Jul 24, 2009 at 4:45 PM, Nikunj R. Mehta<nikunj.mehta@oracle.com 
> > 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

Received on Saturday, 25 July 2009 00:34:56 UTC