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

[Being in a different time zone (IST), was not able to actively engage on this thread :(]

There seems to be Update Loss issue here.  If the UI thread which is supposed to enqueue the statements was scheduled out in the middle of a transaction block.  And the background thread got scheduled in, consumed the already queued items alone part of transaction and committed.  That means, we have lost atomicity right.  I am sure spec did not intend this.  

Am I missing something?

Thanks,
Laxmi

-----Original Message-----
From: Aaron Boodman [mailto:aa@google.com] 
Sent: Saturday, July 25, 2009 6:35 AM
To: Nikunj R. Mehta
Cc: Ian Hickson; public-webapps WG; Laxmi Narsimha Rao Oruganti
Subject: Re: [WebStorage] Concerns on spec section 'Processing Model'

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

4.3.2, step 6 says:

While there are any statements queued up in the transaction, perform
the following steps for each queued up statement in the transaction,
oldest first. Each statement has a statement, optionally a result set
callback, and optionally an error callback.

... then there are the steps to process the statement, handle errors ...

And then step 8 is:

Commit the transaction.

So it seems pretty clear to me that the transaction commits
automatically when there are no more statement queued and all executed
successfully.

Also I helped design this, and I can tell you that was the intent.

> 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?

That is something that is unfortunate. However, it is a browser vendor
requirement to not allow synchronous IO on the UI thread, because it
leads to blocked web pages and browser UI. So there's not really
alternative.

This is part of the reason for the introduction of web workers. They
can allow synchronous IO because the entire program is running on a
separate thread.

> 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.

It does allow it. If an exception is thrown by a developer inside a
statement callback, the transaction will be rolled back:

4.3.2, step 6, substep 6:
If the callback was invoked and raised an exception, jump to the last
step in the overall steps.

> 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?

I think you may be.

It is common when working with databases in C++ to use the RAII
pattern (http://en.wikipedia.org/wiki/Resource_Acquisition_Is_Initialization)
to explicitly scope transactions. This is done to prevent developers
from forgetting to close transactions. The analogue to this pattern in
JavaScript is callbacks.

You can't use RAII in the same way as C++ with Java, but C# introduced
the using statement
(http://msdn.microsoft.com/en-us/library/yh598w02.aspx) to allow the
same sorts of things. In particular, the .net IDbTransaction interface
inherits IDisposable, so that you can use it with the using statement
(http://msdn.microsoft.com/en-us/library/system.data.idbtransaction.aspx),
and that is the recommended pattern.

>> 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.

I still think you're misreading it. In any case, as I have said, if
the spec does say that it is a bug as that was not the intent.

- a

Received on Saturday, 25 July 2009 18:23:12 UTC