On Jul 24, 2009, at 4:25 PM, Aaron Boodman wrote:
On Fri, Jul 24, 2009 at 4:12 PM, Nikunj R. Mehta<[email protected]
> wrote:
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
2. create single-instance-only apps , i.e., hold a write lock on
the
database forever since they don't want to deal version checks.
I don't think you understand the spec - it isn't actually possible
to
hold the lock forever.
It is a little insulting for you to say that, but I will not take
offense to
it.
I didn't mean any offense, I really don't think you understand the
spec completely :).
I beg to differ. Au contraire, I really don't think you understand
databases at all.
Locks aren't an explit part of the API, but are
implicit and released automatically when functions return.
This is completely incorrect. Read below for more details.
Take a look at the transaction method again:
db.transaction(function(tx) {
tx.executeSql(strSql, function() {
});
});
The transaction is implicitly released when the last sql statement
is
completed (or fails). The only way you can keep this transaction
open
is to execute more SQL.
(corrected a slight typo in the example - it was missing the
parameter
definition for tx)
Thanks for the correction. Code is for conversational purposes only. I
also may be forgetting some API details since I haven't looked at this
in awhile.
If I put in a timer or another asynchronous call inside the block
and that
block used the variable tx, wouldn't it force the implementation to
continue
holding the database lock? If so, there is no limit to how long I
can hold
on to variables, and hence I could hold on to the database as an
exclusive
reader/writer for as long as I wanted to. A novice programmer would
probably
not even understand what a transaction means, except that they need a
"handle" to change stuff. That programmer could hold on to this
handle for
the duration of the session.
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.
On Fri, Jul 24, 2009 at 4:13 PM, Nikunj R. Mehta<[email protected]
> wrote:
On Jul 24, 2009, at 3:57 PM, Aaron Boodman wrote:
So you are
reduced to very awkward ways of cooperating -- using the database
itself as a queue or for master election, or designing a separate
transaction system between tabs which might be on separate threads,
using an asynchronous API. Or you just accept that any statement can
fail and retry everything. Or your app is just buggy if multiple
instances are open.
Did you consider for a moment that all this is merely a result of
the SQLite
"feature" to lock the entire database?
No, having the database not be able to change out from under a
multi-step update was a design goal of the API. Implementing a complex
application without exclusive transactions would be very difficult.
I am not proposing to take away your choice. But please don't take
away mine.
It would be useful to see an explanation as to why the proposal I made
[[
add an isolation level parameter with a default value of SERIALIZABLE
and remove the exclusive database-level write lock requirement
]]
is worse than the current spec text. You can refer to SQL92 explain
the meaning of SERIALIZABLE. AFAIK, there are no interoperability
problems with transaction isolation levels.
Nikunj
http://o-micron.blogspot.com
