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.


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]

Reply via email to