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

Reply via email to