On Fri, 12 Oct 2007 01:00:32 -0500, you wrote:
>On Thu, 11 Oct 2007 13:33:35 +0200, Kees Nuyt wrote
>> On Wed, 10 Oct 2007 22:10:38 -0500, you wrote:
>>> You might want to be a little bit more clear about the fact that
>>> [transaction] nests even though BEGIN does not.
>>
>> The TCL transaction{
On Thu, 11 Oct 2007 13:33:35 +0200, Kees Nuyt wrote
> On Wed, 10 Oct 2007 22:10:38 -0500, you wrote:
>> You might want to be a little bit more clear about the fact that
>> [transaction] nests even though BEGIN does not.
>
> The TCL transaction{} can be nested, the SQL BEGIN can't.
It looks like I
The attached patch seems to do it. The thinking-out-loud patch in my
earlier email wasn't right (I'd kept an interim edit from the
PRAGMA-based approach).
I can't think of a reason to have EXCLUSIVE as the default.
-scott
On 10/10/07, Scott Hess <[EMAIL PROTECTED]> wrote:
> On 10/10/07, [EMAIL
On Wed, 10 Oct 2007 22:10:38 -0500, you wrote:
>On Thu, 11 Oct 2007 02:40:22 +, drh wrote
>> The BEGIN, ROLLBACK, and/or COMMIT only happen on the outermost
>> "transaction". Of course, it is kind of silly to nest
>> as shown above. But this is useful, for example, when each
>> "db transact
On Thu, 11 Oct 2007 02:40:22 +, drh wrote
> The BEGIN, ROLLBACK, and/or COMMIT only happen on the outermost
> "transaction". Of course, it is kind of silly to nest
> as shown above. But this is useful, for example, when each
> "db transaction" is really in a separate procedure and the
> proc
"Scott Hess" <[EMAIL PROTECTED]> wrote:
> >
> > 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 ow
On 10/10/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> "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 y
"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.
Such a thing might look something like the attached patch. I'm not
enthusiastic about using an extra byte in the sqlite3 structure. If
it could be reduced to a flag (default deferred, default immediate),
that might be worthwhile.
-scott
On 10/10/07, Ken <[EMAIL PROTECTED]> wrote:
> Scott,
>
>
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
> in
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 d
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 ap
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
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 e
14 matches
Mail list logo
