Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 transaction{} can be nested, the SQL BEGIN can't.
>
>It looks like I'm the one who was unclear. I was asking DRH to consider
>expanding the documentation a bit to underscore the fact that [transaction]
>can be used in nested fashion despite the limitations of BEGIN--- I had
>incorrectly assumed that since BEGIN doesn't nest, [transaction] doesn't nest
>either. Also, I didn't explain my typographical convention: [bracketed] words
>are Tcl commands, CAPITALIZED words are SQL keywords.
In retrospect, I could have done a better job reading your
message.
Ok, all clear now ;)
Regards,
--
( Kees Nuyt
)
c[_]
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 I'm the one who was unclear. I was asking DRH to consider
expanding the documentation a bit to underscore the fact that [transaction]
can be used in nested fashion despite the limitations of BEGIN--- I had
incorrectly assumed that since BEGIN doesn't nest, [transaction] doesn't nest
either. Also, I didn't explain my typographical convention: [bracketed] words
are Tcl commands, CAPITALIZED words are SQL keywords.
--
Andy Goth
<[EMAIL PROTECTED]>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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, [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 you're
> > > multi-threaded you can hit some hard-to-understand cases.
> > >
> > > One suggestion was to use BEGIN IMMEDIATE for explicit transactions,
> > > rather than BEGIN. And it seemed to us like that might be a
> > > reasonable default, given that Gears encourages multiple threads
> > > hitting the same database.
> > >
> > > It looks pretty easy to make this happen (one-line mod to parse.y),
> > > and BEGIN DEFERRED is supported syntax for those who really do mean
> > > that. Does anyone have a strong argument for why we're descending
> > > into a pit of despair by considering this?
> >
> > 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 own
> > built-in methods which in turn runs BEGIN, COMMIT, and
> > ROLLBACK on the user's behalf. If you used this approach,
> > then you could easily revise your method to call BEGIN IMMEDIATE
> > instead of just BEGIN. You could also do the BUSY retry
> > handling that Ken suggests.
>
> Indeed, there has been past discussion about whether we should do some
> sort of transaction API which integrated with the language (for
> instance, automating ROLLBACK on uncaught exceptions). It may be that
> this is the time for that to come back to the fore.
>
> > If you really want to use SQL instead of a separate method,
> > I would suggest a compile-time switch to make IMMEDIATE the
> > default in place of DEFERRED - not a pragma. We already have
> > way too many pragmas. I will be happy to add a compile-time
> > option to make IMMEDATE the default behavior. I will require
> > rather more convincing to add another pragma.
>
> That's a reasonable position to take. For Gears, it would be super
> easy to just make the change directly to parse.y, and I _think_ that I
> understand things well enough to implement
> SQLITE_TRANSACTION_DEFAULT_IMMEDIATE or something along those lines.
>
> Thinking out loud, it looks to me like the change would be something like:
>
> cmd ::= BEGIN transtype(Y) trans_opt. {sqlite3BeginTransaction(pParse, Y);}
> trans_opt ::= .
> trans_opt ::= TRANSACTION.
> trans_opt ::= TRANSACTION nm.
> %type transtype {int}
> + %ifdef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
> + transtype(A) ::= . {A = TK_IMMEDIATE;}
> + %endif
> + %ifndef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
> transtype(A) ::= . {A = 0;}
> + %endif
> transtype(A) ::= DEFERRED(X). {A = @X;}
> transtype(A) ::= IMMEDIATE(X). {A = @X;}
> transtype(A) ::= EXCLUSIVE(X). {A = @X;}
> cmd ::= COMMIT trans_opt. {sqlite3CommitTransaction(pParse);}
> cmd ::= END trans_opt. {sqlite3CommitTransaction(pParse);}
> cmd ::= ROLLBACK trans_opt.{sqlite3RollbackTransaction(pParse);}
>
> I can wrap that up better tomorrow. And maybe even think of a better
> define than SQLITE_TRANSACTION_DEFAULT_IMMEDIATE :-).
>
> -scott
>
Index: src/parse.y
===
RCS file: /sqlite/sqlite/src/parse.y,v
retrieving revision 1.234
diff -u -r1.234 parse.y
--- src/parse.y 21 Aug 2007 10:44:16 - 1.234
+++ src/parse.y 11 Oct 2007 17:39:57 -
@@ -113,7 +113,12 @@
trans_opt ::= TRANSACTION.
trans_opt ::= TRANSACTION nm.
%type transtype {int}
+%ifdef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
+transtype(A) ::= . {A = TK_IMMEDIATE;}
+%endif SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
+%ifndef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
transtype(A) ::= . {A = TK_DEFERRED;}
+%endif SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
transtype(A) ::= DEFERRED(X). {A = @X;}
transtype(A) ::= IMMEDIATE(X). {A = @X;}
transtype(A) ::= EXCLUSIVE(X). {A = @X;}
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 transaction" is really in a separate procedure and the
>> procedures are nested.
>
>Wow, I didn't know [transaction] nests! Thanks. I had written some
>untrustworthy code to only invoke [transaction] on the outermost stack frame;
>it's great to know that I can get rid of it.
>
>From the documentation:
>
>"Also, BEGIN does not nest, so you have to make sure no other transactions
Meaning: SQL transactions
> are active before starting a new one. The 'transaction' method takes
> care of all of these details automatically."
And this is about the TCL transaction {} method.
>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.
As drh wrote:
>> The BEGIN, ROLLBACK, and/or COMMIT only happen
>> on the outermost "transaction".
--
( Kees Nuyt
)
c[_]
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 > procedures are nested. Wow, I didn't know [transaction] nests! Thanks. I had written some untrustworthy code to only invoke [transaction] on the outermost stack frame; it's great to know that I can get rid of it. >From the documentation: "Also, BEGIN does not nest, so you have to make sure no other transactions are active before starting a new one. The 'transaction' method takes care of all of these details automatically." You might want to be a little bit more clear about the fact that [transaction] nests even though BEGIN does not. -- Andy Goth <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Making BEGIN IMMEDIATE the default.
"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 own
> > built-in methods which in turn runs BEGIN, COMMIT, and
> > ROLLBACK on the user's behalf. If you used this approach,
> > then you could easily revise your method to call BEGIN IMMEDIATE
> > instead of just BEGIN. You could also do the BUSY retry
> > handling that Ken suggests.
>
> Indeed, there has been past discussion about whether we should do some
> sort of transaction API which integrated with the language (for
> instance, automating ROLLBACK on uncaught exceptions). It may be that
> this is the time for that to come back to the fore.
>
Exactly. Notice how the TCL bindings do this. If "db" is
the object that is your database connection then you do:
db transaction {
# lots of other code.
db eval {--SQL} ...
# more code
}
And if an exception gets thrown inside the {...} and doesn't
get caught before leaving the {...} the transaction is
automatically rolled back. Furthermore, you can nest the
"db transaction" implementations:
db transaction {
db transaction {
db transaction {
#...
}
}
}
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
procedures are nested.
This is all relatively easy to implement for TCL where every
string is also a lambda procedure. It isn't clear to me if
or how you could do the same in javascript. But if you have
a javascript guru who can pull it off, it would be neat.
--
D. Richard Hipp <[EMAIL PROTECTED]>
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 you're
> > multi-threaded you can hit some hard-to-understand cases.
> >
> > One suggestion was to use BEGIN IMMEDIATE for explicit transactions,
> > rather than BEGIN. And it seemed to us like that might be a
> > reasonable default, given that Gears encourages multiple threads
> > hitting the same database.
> >
> > It looks pretty easy to make this happen (one-line mod to parse.y),
> > and BEGIN DEFERRED is supported syntax for those who really do mean
> > that. Does anyone have a strong argument for why we're descending
> > into a pit of despair by considering this?
>
> 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 own
> built-in methods which in turn runs BEGIN, COMMIT, and
> ROLLBACK on the user's behalf. If you used this approach,
> then you could easily revise your method to call BEGIN IMMEDIATE
> instead of just BEGIN. You could also do the BUSY retry
> handling that Ken suggests.
Indeed, there has been past discussion about whether we should do some
sort of transaction API which integrated with the language (for
instance, automating ROLLBACK on uncaught exceptions). It may be that
this is the time for that to come back to the fore.
> If you really want to use SQL instead of a separate method,
> I would suggest a compile-time switch to make IMMEDIATE the
> default in place of DEFERRED - not a pragma. We already have
> way too many pragmas. I will be happy to add a compile-time
> option to make IMMEDATE the default behavior. I will require
> rather more convincing to add another pragma.
That's a reasonable position to take. For Gears, it would be super
easy to just make the change directly to parse.y, and I _think_ that I
understand things well enough to implement
SQLITE_TRANSACTION_DEFAULT_IMMEDIATE or something along those lines.
Thinking out loud, it looks to me like the change would be something like:
cmd ::= BEGIN transtype(Y) trans_opt. {sqlite3BeginTransaction(pParse, Y);}
trans_opt ::= .
trans_opt ::= TRANSACTION.
trans_opt ::= TRANSACTION nm.
%type transtype {int}
+ %ifdef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
+ transtype(A) ::= . {A = TK_IMMEDIATE;}
+ %endif
+ %ifndef SQLITE_TRANSACTION_DEFAULT_IMMEDIATE
transtype(A) ::= . {A = 0;}
+ %endif
transtype(A) ::= DEFERRED(X). {A = @X;}
transtype(A) ::= IMMEDIATE(X). {A = @X;}
transtype(A) ::= EXCLUSIVE(X). {A = @X;}
cmd ::= COMMIT trans_opt. {sqlite3CommitTransaction(pParse);}
cmd ::= END trans_opt. {sqlite3CommitTransaction(pParse);}
cmd ::= ROLLBACK trans_opt.{sqlite3RollbackTransaction(pParse);}
I can wrap that up better tomorrow. And maybe even think of a better
define than SQLITE_TRANSACTION_DEFAULT_IMMEDIATE :-).
-scott
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
Re: [sqlite] Making BEGIN IMMEDIATE the default.
"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. > > One suggestion was to use BEGIN IMMEDIATE for explicit transactions, > rather than BEGIN. And it seemed to us like that might be a > reasonable default, given that Gears encourages multiple threads > hitting the same database. > > It looks pretty easy to make this happen (one-line mod to parse.y), > and BEGIN DEFERRED is supported syntax for those who really do mean > that. Does anyone have a strong argument for why we're descending > into a pit of despair by considering this? > 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 own built-in methods which in turn runs BEGIN, COMMIT, and ROLLBACK on the user's behalf. If you used this approach, then you could easily revise your method to call BEGIN IMMEDIATE instead of just BEGIN. You could also do the BUSY retry handling that Ken suggests. If you really want to use SQL instead of a separate method, I would suggest a compile-time switch to make IMMEDIATE the default in place of DEFERRED - not a pragma. We already have way too many pragmas. I will be happy to add a compile-time option to make IMMEDATE the default behavior. I will require rather more convincing to add another pragma. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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,
>
> 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 default begin
> "deffered/immediate/exclusive" would be nice :)
>
> Ken
>
>
> Scott Hess <[EMAIL PROTECTED]> wrote: 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 appropriate places. This is a little bit of a
> departure from using SQLite in an embedded environment.
>
> -scott
>
>
> On 10/10/07, John Stanton wrote:
> > 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. 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 explicit transactions,
> > > rather than BEGIN. And it seemed to us like that might be a
> > > reasonable default, given that Gears encourages multiple threads
> > > hitting the same database.
> > >
> > > It looks pretty easy to make this happen (one-line mod to parse.y),
> > > and BEGIN DEFERRED is supported syntax for those who really do mean
> > > that. Does anyone have a strong argument for why we're descending
> > > into a pit of despair by considering this?
> > >
> > > Thanks,
> > > scott
>
> -
> To unsubscribe, send email to [EMAIL PROTECTED]
> -
>
>
>
Index: src/build.c
===
RCS file: /sqlite/sqlite/src/build.c,v
retrieving revision 1.445
diff -u -r1.445 build.c
--- src/build.c 4 Oct 2007 18:11:16 - 1.445
+++ src/build.c 11 Oct 2007 00:02:21 -
@@ -3092,6 +3092,7 @@
v = sqlite3GetVdbe(pParse);
if( !v ) return;
+ if( !type ) type = db->dfltTransMode;
if( type!=TK_DEFERRED ){
for(i=0; inDb; i++){
sqlite3VdbeAddOp(v, OP_Transaction, i, (type==TK_EXCLUSIVE)+1);
Index: src/parse.y
===
RCS file: /sqlite/sqlite/src/parse.y,v
retrieving revision 1.234
diff -u -r1.234 parse.y
--- src/parse.y 21 Aug 2007 10:44:16 - 1.234
+++ src/parse.y 11 Oct 2007 00:02:21 -
@@ -113,7 +113,7 @@
trans_opt ::= TRANSACTION.
trans_opt ::= TRANSACTION nm.
%type transtype {int}
-transtype(A) ::= . {A = TK_DEFERRED;}
+transtype(A) ::= . {A = 0;}
transtype(A) ::= DEFERRED(X). {A = @X;}
transtype(A) ::= IMMEDIATE(X). {A = @X;}
transtype(A) ::= EXCLUSIVE(X). {A = @X;}
Index: src/pragma.c
===
RCS file: /sqlite/sqlite/src/pragma.c,v
retrieving revision 1.149
diff -u -r1.149 pragma.c
--- src/pragma.c31 Aug 2007 18:34:59 - 1.149
+++ src/pragma.c11 Oct 2007 00:02:21 -
@@ -84,6 +84,17 @@
}
#endif /* ifndef SQLITE_OMIT_AUTOVACUUM */
+static int getTransactionMode(const char *z){
+ int i;
+ if( 0==sqlite3StrICmp(z, "deferred") ) return TK_DEFERRED;
+ if( 0==sqlite3StrICmp(z, "immediate") ) return TK_IMMEDIATE;
+ if( 0==sqlite3StrICmp(z, "exclusive") ) return TK_EXCLUSIVE;
+ i = atoi(z);
+ if( i==1 ) return TK_IMMEDIATE;
+ if( i==2 ) return TK_EXCLUSIVE;
+ return TK_DEFERRED;
+}
+
#ifndef SQLITE_OMIT_PAGER_PRAGMAS
/*
** Interpret the given string as a temp db location. Return 1 for file
@@ -492,6 +503,24 @@
}else
#endif
+ /*
+ ** PRAGMA [database.]transaction_mode
+ ** PRAGMA [database.]transaction_mode = 0 | deferred | 1 | immediate | 2 |
exclusive
+ **
+ */
+ if( sqlite3StrICmp(zLeft,"transaction_mode")==0 ){
+if( sqlite3ReadSchema(pParse) ) goto pragma_out;
+if( !zRight ){
+ int mode = 0;
+ if( db->dfltTransMode==TK_IMMEDIATE ) mode = 1;
+ if( db->dfltTransMode==TK_EXCLUSIVE ) mode = 2;
+ returnSingleInt(pParse, "transaction_mode", mode );
+}else{
+ db->dfltTransMode = getTransactionMode(zRight);
+}
+ }else
+
+
#ifndef SQLITE_OMIT_PAGER_PRAGMAS
/*
** PRAGMA [database.]cache_size
Index:
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 > 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 appropriate places. This is a little bit of a > departure from using SQLite in an embedded environment. > > -scott > > > On 10/10/07, John Stanton <[EMAIL PROTECTED]> wrote: > > 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. 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 explicit transactions, > > > rather than BEGIN. And it seemed to us like that might be a > > > reasonable default, given that Gears encourages multiple threads > > > hitting the same database. > > > > > > It looks pretty easy to make this happen (one-line mod to parse.y), > > > and BEGIN DEFERRED is supported syntax for those who really do mean > > > that. Does anyone have a strong argument for why we're descending > > > into a pit of despair by considering this? > > > > > > Thanks, > > > scott > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 default begin "deffered/immediate/exclusive" would be nice :) Ken Scott Hess <[EMAIL PROTECTED]> wrote: 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 appropriate places. This is a little bit of a departure from using SQLite in an embedded environment. -scott On 10/10/07, John Stanton wrote: > 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. 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 explicit transactions, > > rather than BEGIN. And it seemed to us like that might be a > > reasonable default, given that Gears encourages multiple threads > > hitting the same database. > > > > It looks pretty easy to make this happen (one-line mod to parse.y), > > and BEGIN DEFERRED is supported syntax for those who really do mean > > that. Does anyone have a strong argument for why we're descending > > into a pit of despair by considering this? > > > > Thanks, > > scott - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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 appropriate places. This is a little bit of a departure from using SQLite in an embedded environment. -scott On 10/10/07, John Stanton <[EMAIL PROTECTED]> wrote: > 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. 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 explicit transactions, > > rather than BEGIN. And it seemed to us like that might be a > > reasonable default, given that Gears encourages multiple threads > > hitting the same database. > > > > It looks pretty easy to make this happen (one-line mod to parse.y), > > and BEGIN DEFERRED is supported syntax for those who really do mean > > that. Does anyone have a strong argument for why we're descending > > into a pit of despair by considering this? > > > > Thanks, > > scott - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] Making BEGIN IMMEDIATE the default.
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. 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 explicit transactions, rather than BEGIN. And it seemed to us like that might be a reasonable default, given that Gears encourages multiple threads hitting the same database. It looks pretty easy to make this happen (one-line mod to parse.y), and BEGIN DEFERRED is supported syntax for those who really do mean that. Does anyone have a strong argument for why we're descending into a pit of despair by considering this? Thanks, scott - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] Making BEGIN IMMEDIATE the default.
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 explicit transactions, rather than BEGIN. And it seemed to us like that might be a reasonable default, given that Gears encourages multiple threads hitting the same database. It looks pretty easy to make this happen (one-line mod to parse.y), and BEGIN DEFERRED is supported syntax for those who really do mean that. Does anyone have a strong argument for why we're descending into a pit of despair by considering this? Thanks, scott - To unsubscribe, send email to [EMAIL PROTECTED] -
