Hello,
I was under the impress that we could never
get an SQLITE_BUSY, not even on COMMIT if
we use BEGIN EXCLUSIVE. But this seems to
say that COMMITs on exclusive transactions
can through SQLITE_BUSY?...
--- [EMAIL PROTECTED] wrote:
then start the transaction initially with BEGIN
Kervin L. Pierre [EMAIL PROTECTED] wrote:
Hello,
I was under the impress that we could never
get an SQLITE_BUSY, not even on COMMIT if
we use BEGIN EXCLUSIVE. But this seems to
say that COMMITs on exclusive transactions
can through SQLITE_BUSY?...
You can get an SQLITE_BUSY on the
: [sqlite] Problems with multiple threads?
* Pat Wibbeler [EMAIL PROTECTED] [2006-06-07 22:55]:
It's entirely possible I'm reading these docs incorrectly, but
this strategy has worked quite well for me.
No, I don't see any error in your reading. My apologies; I should
have consulted the docs instead
As various people search for application and/or SQLite bugs
related to multiple threads and BEGIN, let me try to aid the
effort by better describing exactly what BEGIN does and
suggesting some debugging tricks.
Realize that BEGIN does not actually create any file locks
or check to see if any
For me, I have a bunch of threads writing to the database. That is the only
part I do multithreaded. (All my read queries are handled after all the data
is written.) I just use the scoped_lock operator from the Boost library at
the top of my function that does the bind and step calls. I pass a
On 6/7/06, Russell Leighton [EMAIL PROTECTED] wrote:
So, this was very enlightening...I have a simple backup function that I
now question is correct.
It does:
- execute begin // lock from writes
-copy db file to new file byte by byte
- execute commit // unlock
...I was thinking
Thanks for an additional explanation, I used sqlite3_get_autocommit() for
debugging and it helped me to find out that it really was my fault. There
was an incorrect processing after COMMIT returned SQLITE_BUSY. So sorry for
this.
However, right after fixing this, I found another problem. It
On 6/7/06, Jiri Hajek [EMAIL PROTECTED] wrote:
However, right after fixing this, I found another problem. It certainly can
be my fault, but I don't see how could it be: If I don't use transactions,
multiple threads seem to proceed well, but then right after I add BEGIN and
COMMIT to some place,
On Wed, 7 Jun 2006, Jiri Hajek wrote:
However, right after fixing this, I found another problem. It certainly can
be my fault, but I don't see how could it be: If I don't use transactions,
multiple threads seem to proceed well, but then right after I add BEGIN and
COMMIT to some place, all
Thx!
[EMAIL PROTECTED] wrote:
Russell Leighton [EMAIL PROTECTED] wrote:
So, this was very enlightening...I have a simple backup function that I
now question is correct.
It does:
- execute begin // lock from writes
-copy db file to new file byte by byte
- execute commit //
Message-
From: Russell Leighton [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 07, 2006 8:24 AM
To: sqlite-users@sqlite.org
Subject: [sqlite] BEGIN and Backup [was Re: [sqlite] Problems with
multiple threads?]
So, this was very enlightening...I have a simple backup function that I
now question
[was [sqlite] Problems with multiple
threads?]
Discusses a similar issue.
Pat
-Original Message-
From: Jiri Hajek [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 07, 2006 9:26 AM
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Problems with multiple threads?
Thanks for an additional
Pat Wibbeler [EMAIL PROTECTED] wrote:
You can use BEGIN IMMEDIATE or BEGIN EXCLUSIVE depending on the type of
lock you'd like.
If you are just trying to make sure the database does
not change while you back it up, then Jay's suggestion
of BEGIN IMMEDIATE is the better approach (better than
my
Christian Smith [EMAIL PROTECTED] wrote:
On Wed, 7 Jun 2006, Jiri Hajek wrote:
However, right after fixing this, I found another problem. It certainly can
be my fault, but I don't see how could it be: If I don't use transactions,
multiple threads seem to proceed well, but then right after
If it is inconvenient to rollback and retry the entire transaction, then
start the transaction initially with BEGIN EXCLUSIVE.
This will acquire the reserved lock immediately (instead of waiting to the
first write occurs) and so you will either get an
SQLITE_BUSY right away (when it is a
To: sqlite-users@sqlite.org
Subject: RE: [sqlite] Problems with multiple threads?
If it is inconvenient to rollback and retry the entire transaction,
then
start the transaction initially with BEGIN EXCLUSIVE.
This will acquire the reserved lock immediately (instead of waiting to
the
first write
* Pat Wibbeler [EMAIL PROTECTED] [2006-06-07 20:50]:
Beginning everything with BEGIN IMMEDIATE should eliminate the
possibility of deadlock, but you will serialize read-only
operations.
Why? BEGIN IMMEDIATE acquires a for-read lock. Multiple for-read
locks can be acquired concurrently. It is
Bill King wrote:
It would be nice if SQLite told us this. However, SQLite detects the
reserved lock and returns SQLITE_BUSY, telling niether transaction
much other than to try again. If a reserved lock is detected when
trying to promote an existing read lock, this is a deadlock situation
[EMAIL PROTECTED] wrote:
Bill King [EMAIL PROTECTED] wrote:
Christian Smith wrote:
If one transaction already has a read lock, and another transaction
has a reserved lock (trying to get a write lock), neither thread can
get a write lock. One of the transactions must abort.
Such
Jay Sprenkle wrote:
On 6/7/06, Bill KING [EMAIL PROTECTED] wrote:
I understand why I'm getting the deadlock now, lazy locking, (it's
against the logical grain of transaction/locking, but that's a whole
other argument) . Maybe this should be highlighted with big arrows in
the information
* Pat Wibbeler [EMAIL PROTECTED] [2006-06-07 22:55]:
It's entirely possible I'm reading these docs incorrectly, but
this strategy has worked quite well for me.
No, I don’t see any error in your reading. My apologies; I should
have consulted the docs instead of going by mailing list posts.
It’s
--- Nathaniel Smith [EMAIL PROTECTED] wrote:
On Wed, Jun 07, 2006 at 01:24:38PM -0400, [EMAIL PROTECTED] wrote:
If it is inconvenient to rollback and retry the entire transaction,
then start the transaction initially with BEGIN EXCLUSIVE. This
will acquire the reserved lock immediately
Hello,
I'm trying to use SQLite in an application where it's needed to work with
one database in mutliple threads. Based on all the info I read in SQLite
documentation I create a new database connection for every new thread
created. Each thread does some SELECTs, INSERTs or UPDATEs, but there
Jiri Hajek wrote:
Hello,
I'm trying to use SQLite in an application where it's needed to work with
one database in mutliple threads. Based on all the info I read in SQLite
documentation I create a new database connection for every new thread
created. Each thread does some SELECTs, INSERTs or
Synchronize you database access so that only one transaction is current
and is finalized on cpmpletion. In other words serialize it. You can
use a mutex or similar to achieve synchronization.
Look back at the recent discussion on this forum.
Jiri Hajek wrote:
Hello,
I'm trying to use
Jiri Hajek [EMAIL PROTECTED] writes:
1. Occasionally after running Sqlite3_step() I get SQLITE_CANTOPEN ('Unable
to open the database file') error. I found out that it can be fixed by
running the query again, i.e. again calling Sqlite3_Prepare(). So this isn't
a big issue, but still I wonder
[EMAIL PROTECTED] wrote:
Jiri Hajek [EMAIL PROTECTED] writes:
1. Occasionally after running Sqlite3_step() I get SQLITE_CANTOPEN ('Unable
to open the database file') error. I found out that it can be fixed by
running the query again, i.e. again calling Sqlite3_Prepare(). So this isn't
a
Jiri Hajek [EMAIL PROTECTED] wrote:
1. Occasionally after running Sqlite3_step() I get SQLITE_CANTOPEN ('Unable
to open the database file') error. I found out that it can be fixed by
running the query again, i.e. again calling Sqlite3_Prepare(). So this isn't
a big issue, but still I wonder
[EMAIL PROTECTED] wrote:
Jiri Hajek [EMAIL PROTECTED] wrote:
1. Occasionally after running Sqlite3_step() I get SQLITE_CANTOPEN ('Unable
to open the database file') error. I found out that it can be fixed by
running the query again, i.e. again calling Sqlite3_Prepare(). So this isn't
a
Bill KING [EMAIL PROTECTED] wrote:
Could this be cause by one thread opening a transaction, then a second
on a second connection trying to open a transaction on it, and failing
to open the transaction file (as it already exists?).
No.
Each database connection (each sqlite3* pointer) has a
Hi Bill,
When you say handle read/write locking [your]self do
you mean outside of SQLite in your code or by altering
SQLite's source code?
What algorithm do you employ?
--- Bill KING [EMAIL PROTECTED] wrote:
I personally did do all this, this doesn't solve the issue. As I
mentioned earlier,
[EMAIL PROTECTED] wrote:
Bill KING [EMAIL PROTECTED] wrote:
Could this be cause by one thread opening a transaction, then a second
on a second connection trying to open a transaction on it, and failing
to open the transaction file (as it already exists?).
No.
Each database connection
Joe Wilson wrote:
Hi Bill,
When you say handle read/write locking [your]self do
you mean outside of SQLite in your code or by altering
SQLite's source code?
What algorithm do you employ?
--- Bill KING [EMAIL PROTECTED] wrote:
I personally did do all this, this doesn't solve the
Joe Wilson wrote:
--- Bill KING [EMAIL PROTECTED] wrote:
Outside of, and I use Qt's QReadWriteLock. -lockForRead()/lockForWrite()
http://doc.trolltech.com/4.1/qreadwritelock.html
Thanks.
Many follow-up questions... :-)
Is this for an application or for the Qt SQLite database
when I see this issue.
Pat
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 06, 2006 6:36 PM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Problems with multiple threads?
Bill KING [EMAIL PROTECTED] wrote:
Could this be cause by one thread
35 matches
Mail list logo