W3C home > Mailing lists > Public > whatwg@whatwg.org > October 2007

[whatwg] SQL API and closeTransaction()

From: Brady Eidson <beidson@apple.com>
Date: Thu, 4 Oct 2007 19:06:55 -0700
Message-ID: <D77D5B77-2FBC-47D3-B360-38A99D95E618@apple.com>
I know there has been a little discussion in the last few weeks on  
this point, but I don't know that anything was decided and the spec is  
certainly still ambiguous.

 From the definition of the Database object -
"void closeTransaction(); // only needed as part of error recovery"

Then later described -
"The closeTransaction() method may be called while in a callback  
called by the executeSql() method. When the method is invoked, it must  
clear any active thread-global transaction..."

This is too vague.

The implication in the Database object spec is that closeTransaction()  
is only meant for error recovery, implying that an explicit call to  
closeTransaction() will always rollback the active thread-global  
transaction.
But the description of the method says closeTransaction() will "clear"  
any active thread-global transaction.  What does "clear" mean?  Does  
this mean commit, or rollback?
If the transaction is marked as bad, "rollback" is obviously  
appropriate - but what if the transaction isn't marked bad?  What if  
the developer just wants to commit the active thread-global  
transaction for his own transactional management?

I don't think the spec would suffer any if closeTransaction() was  
replaced with commitTransaction() and rollbackTransaction().  The only  
additional complexity would be specifying that if the developer tries  
to commit a bad transaction, an exception is thrown.

If we stick with just closeTransaction(), at the very least the spec  
needs to be more precise on what closeTransaction() actually does.

Thanks,
~Brady
Received on Thursday, 4 October 2007 19:06:55 UTC

This archive was generated by hypermail 2.3.1 : Monday, 13 April 2015 23:08:37 UTC