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] -----------------------------------------------------------------------------
