"D. Richard Hipp" <[EMAIL PROTECTED]> writes:
> [EMAIL PROTECTED] wrote:
> > What I'm seeing is a few tasks doing lots of writing to the database (with
> > and without explicit transactions) preventing a reader task from getting a
> > chance to read. A SELECT can block for a *very* long time (
[EMAIL PROTECTED] wrote:
> What I'm seeing is a few tasks doing lots of writing to the database (with
> and without explicit transactions) preventing a reader task from getting a
> chance to read. A SELECT can block for a *very* long time (my 60 second
> timeout expires).
>
What you describe is no
"D. Richard Hipp" <[EMAIL PROTECTED]> writes:
> Version 2 had a problem with writer starvation. I'm not familiar with
> the reader starvation problem. Can you describe your situation?
Maybe I misremembered the terminology. What I'm seeing is a few tasks doing
lots of writing to the database (w
[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 e
"D. Richard Hipp" <[EMAIL PROTECTED]> writes:
> 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 mid
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 of
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 a
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 of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Michael Roth wrote:
| Maybe a solution would be something like this:
|
| All open transactions should have the same chance to commit. The first
| transaction that commits, will win. After a transaction won, all other
| transaction should return BUSY.
I
-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 );-> SQLITE_BU
> > 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, 2004,
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: E
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: END TRANSACTION;
Is this
PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, August 11, 2004 2:12 AM
Subject: [sqlite] Deadlock when doing threaded updates and inserts
> I'm running into a deadlock, as the subject says, when doing updates on
> a table in one thread while another thread is inserting
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: END TRANSACTION;
Is this a bug? Or do I have t
Hello SQLite Users,
Hello Dr. Hipp,
> After the db1 transaction ends, the db2 UPDATE should be able to
> complete. In version 2, db2 would have blocked when it tried to
> begin the transaction. Version 3 allows db2 to continue future,
> but you still cannot have two threads changing the same data
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 transa
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 SQLITE
24 matches
Mail list logo
