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