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