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

[whatwg] Comments on updated SQL API

From: Maciej Stachowiak <mjs@apple.com>
Date: Wed, 17 Oct 2007 00:31:38 -0700
Message-ID: <9F3B5FC9-9649-4951-8694-DABB9F68387E@apple.com>

On Oct 16, 2007, at 11:18 PM, Ian Hickson wrote:

> On Fri, 5 Oct 2007, Scott Hess wrote:
>
>> In general, I am of the opinion that you should either have no
>> transactions, or explicit transactions, but never implicit  
>> transactions.
>> This is a little different from a case like mysql, where you might  
>> make
>> an explicit decision to do things without transactions in the  
>> interest
>> of scalability, with the associated need to be very careful in how  
>> your
>> system orders your execution.  At least for SQLite, having a  
>> transaction
>> for multiple statements is more efficient than not, and scalability
>> isn't a huge issue.  Even so, I think that implicit transactions are
>> making a decision on behalf of the developer which the developer  
>> should
>> be explicit about.
>
> What are the disadvantages of implicit transactions?
>
> What do other people think?

I can think of two reasons you might not want to open a transaction in  
a particular case.

(1) Behavior - you may honestly want to start a completely independent  
statement from the callback for another. This case seems to be handled  
ok by closeTransaction(), though perhaps a little inconveniently if  
this turns out to be the common case.

(2) Performance for single statements. We should gain implementation  
experience to determine if, in likely implementations, it is a  
significant performance improvement for single statements to be  
executed without opening a transaction at all.

(3) Performance in the face of concurrency by not holding locks as  
long. But again closeTranscation() can cover this case if (2) is not  
an issue.

So I think we need some performance results for (2) to decide if  
another method is warranted.

>> I wasn't clear from the spec, but I think it would be possible to  
>> do the
>> sequence-of-statements case like:
>>
>>  executeSql('sql1', function (result) {
>>    closeTransaction();
>>    executeSql('sql2', function (result) {
>>      closeTransaction();
>>      executeSql('sql3', function (result) {
>>      });
>>    });
>>  });
>>
>> If not, then I think this would be a useful addition (if implicit
>> transactions are retained).
Received on Wednesday, 17 October 2007 00:31:38 UTC

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