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