[EMAIL PROTECTED] wrote:
I'll look into adding a PRAGMA that makes BEGIN TRANSACTION acquire
a RESERVED lock immediately. That will reduce the amount of confusion
about this issue, I suppose.
Does enabling this PRAGMA regenerate the reader starvation problem of 2.8.x,
or is that problem solved
Tito Ciuro wrote:
I'm definitely not happy about this...
Let me get this right... it seems that you're cruising along fine with
SQLITE_OK's all over the place when suddenly one of your
threads/processes get a SQLITE_BUSY signal in the middle of a
transaction. In order to solve the crisis, one
On Aug 11, 2004, at 3:48 PM, Dave Hayden wrote:
Since only one of the competing threads will have completed a write
(right?), can't the others "postpone" their transactions somehow until
they can get a write lock?
That is, postpone the "begin transaction" action. Since they haven't
really done
I'm definitely not happy about this...
Let me get this right... it seems that you're cruising along fine with
SQLITE_OK's all over the place when suddenly one of your
threads/processes get a SQLITE_BUSY signal in the middle of a
transaction. In order to solve the crisis, one of the transactions
Good point...
I have several different tasks(vxworks)
Perhaps, this is why its working well for me...
Tezo.
- Original Message -
From: "Dave Hayden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 4:30 PM
Subject: Re: [sqlit
For now, I've solved the problem by adding my own locks to exclude
simultaneous transactions on the same database file.
Ok, but this works only if your app is the only one that can access the
DB. If some other app tries to access the same DB you can go in the
usual deadlock.
Paolo
On Aug 11, 2004, at 4:05 PM, tezozomoc wrote:
I have solved this problem by writing a wrappers around sql_exec and
sql_query, sql_step, etc...
In these wrappers I handle the waiting for busy and the lock file
issue...
I was doing the same, calling usleep() whenever I got a SQLITE_BUSY
return and
.
Tezozomoc.
- Original Message -
From: "Dave Hayden" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 3:48 PM
Subject: Re: [sqlite] Deadlock when doing threaded updates and inserts
> On Aug 11, 2004, at 6:49 AM, D. Richard Hipp wr
On Aug 11, 2004, at 6:49 AM, D. Richard Hipp wrote:
Oops. The db1 should do a ROLLBACK, not a COMMIT. Or db2 can
do an END TRANSACTION (since it never made any changes) and allow
db1 to complete instead. The point is that when two threads or
processes are trying to write at the same time, one
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paolo Vernazza wrote:
| But doing in that way, you can have this behaviour (and this is what
| happends to me):
|
| db1: BEGIN TRANSACTION;-> SQLITE_OK
| db2: BEGIN TRANSACTION;-> SQLITE_OK
|
| db1: INSERT INTO test VALUES ( 1 );->
> > The point is that when two threads or
> > processes are trying to write at the same time, one of the two
> > must back off, abandon their transaction (using ROLLBACK) and let
> > the other proceed.
>
> And how can this be done? What if there are more threads involved? Who
> decides?
>
I found
Hello,
The point is that when two threads or
processes are trying to write at the same time, one of the two
must back off, abandon their transaction (using ROLLBACK) and let
the other proceed.
And how can this be done? What if there are more threads involved? Who
decides?
-- Tito
On Aug 11,
D. Richard Hipp wrote:
Paolo Vernazza wrote:
D. Richard Hipp wrote:
Dave Hayden wrote:
I'm running into a deadlock,
db1: BEGIN TRANSACTION;
db2: BEGIN TRANSACTION;
db1: INSERT INTO test VALUES ( 1 );
At this point, both of these return SQLITE_BUSY:
db2: UPDATE test SET num = 2 WHERE num = 1;
db1:
Dave Hayden wrote:
I'm running into a deadlock, as the subject says, when doing updates on
a table in one thread while another thread is inserting into the same
table. (Oh, and this is on 3.0.4, compiled with --enable-threadsafe)
The update thread returns from its UPDATE command (within a
I'm running into a deadlock, as the subject says, when doing updates on
a table in one thread while another thread is inserting into the same
table. (Oh, and this is on 3.0.4, compiled with --enable-threadsafe)
The update thread returns from its UPDATE command (within a
transaction) with
15 matches
Mail list logo
