Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-12 Thread Kees Nuyt
On Fri, 12 Oct 2007 01:00:32 -0500, you wrote: >On Thu, 11 Oct 2007 13:33:35 +0200, Kees Nuyt wrote >> On Wed, 10 Oct 2007 22:10:38 -0500, you wrote: >>> You might want to be a little bit more clear about the fact that >>> [transaction] nests even though BEGIN does not. >> >> The TCL

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-12 Thread Andy Goth
On Thu, 11 Oct 2007 13:33:35 +0200, Kees Nuyt wrote > On Wed, 10 Oct 2007 22:10:38 -0500, you wrote: >> You might want to be a little bit more clear about the fact that >> [transaction] nests even though BEGIN does not. > > The TCL transaction{} can be nested, the SQL BEGIN can't. It looks like

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-11 Thread Scott Hess
The attached patch seems to do it. The thinking-out-loud patch in my earlier email wasn't right (I'd kept an interim edit from the PRAGMA-based approach). I can't think of a reason to have EXCLUSIVE as the default. -scott On 10/10/07, Scott Hess <[EMAIL PROTECTED]> wrote: > On 10/10/07,

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-11 Thread Kees Nuyt
On Wed, 10 Oct 2007 22:10:38 -0500, you wrote: >On Thu, 11 Oct 2007 02:40:22 +, drh wrote >> The BEGIN, ROLLBACK, and/or COMMIT only happen on the outermost >> "transaction". Of course, it is kind of silly to nest >> as shown above. But this is useful, for example, when each >> "db

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Andy Goth
On Thu, 11 Oct 2007 02:40:22 +, drh wrote > The BEGIN, ROLLBACK, and/or COMMIT only happen on the outermost > "transaction". Of course, it is kind of silly to nest > as shown above. But this is useful, for example, when each > "db transaction" is really in a separate procedure and the >

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread drh
"Scott Hess" <[EMAIL PROTECTED]> wrote: > > > > Many (most?) of the other teams using SQLite in situations > > similar to Gears have their own separate methods for starting, > > committing, and rolling back transactions. They don't run > > BEGIN, COMMIT, or ROLLBACK statements - they call their

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Scott Hess
On 10/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > "Scott Hess" <[EMAIL PROTECTED]> wrote: > > We've just had a bit of discussion on the Google Gears team about some > > cases where failure of an UPDATE/DELETE/INSERT while within a > > transaction is unexpected. Well, that and that when

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread drh
"Scott Hess" <[EMAIL PROTECTED]> wrote: > We've just had a bit of discussion on the Google Gears team about some > cases where failure of an UPDATE/DELETE/INSERT while within a > transaction is unexpected. Well, that and that when you're > multi-threaded you can hit some hard-to-understand cases.

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Scott Hess
Such a thing might look something like the attached patch. I'm not enthusiastic about using an extra byte in the sqlite3 structure. If it could be reduced to a flag (default deferred, default immediate), that might be worthwhile. -scott On 10/10/07, Ken <[EMAIL PROTECTED]> wrote: > Scott, > >

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Scott Hess
Clarify^2: I'm suggesting for our use of SQLite in Google Gears. NOT for SQLite itself. Though Ken's suggestion of a PRAGMA might be interesting for SQLite core... -scott On 10/10/07, Scott Hess <[EMAIL PROTECTED]> wrote: > To clarify, this is for Google Gears, a JavaScript library which >

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Ken
Scott, I found that using begin imediate was very helpful. But it didn't quite fix everything. I ended up wrapping the begin immediate with some retry logic when a sqlite busy is encounted. Once you get the transaction you shouldn't have any isuses with DML. A pragma that could configure the

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Scott Hess
To clarify, this is for Google Gears, a JavaScript library which includes a Database component which is implemented using SQLite. If we were simply building an app on top of SQLite, then the distinction between BEGIN and BEGIN IMMEDIATE would be no problem - we'd just use the right thing in the

Re: [sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread John Stanton
If you are going to use BEGIN IMMEDIATE why not just enclose the transaction in some form of lock like a mutex? Scott Hess wrote: We've just had a bit of discussion on the Google Gears team about some cases where failure of an UPDATE/DELETE/INSERT while within a transaction is unexpected.

[sqlite] Making BEGIN IMMEDIATE the default.

2007-10-10 Thread Scott Hess
We've just had a bit of discussion on the Google Gears team about some cases where failure of an UPDATE/DELETE/INSERT while within a transaction is unexpected. Well, that and that when you're multi-threaded you can hit some hard-to-understand cases. One suggestion was to use BEGIN IMMEDIATE for