Yes but I'd rather move to another database solution then.
As I see it, sqlite could well have such system built-in, no, it wouldnt be
bloat.
The queue system will work, as I mentioned I already thought of it, but, I
don't think its an elegant solution.
I could avoid the "can't read while writing" if SQLITE was better designed.
It could have a memory buffer system at least.
----- Original Message -----
From: "Michael Ruck" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, July 12, 2006 2:53 PM
Subject: AW: [sqlite] Problems with Multi-Threaded Application.
I would suggest using a queue approach. Its not as bad as it sounds. Have
that queue processed by a single thread, which controls the database writes.
That way you can save the time for other operations, such as database
open/close etc.
You can't avoid the "can't read while writing" though. You'll have to figure
out something for this. I'd use a named mutex (or similar IPC) for this. Or:
Serialize all database access via a queue and a single threaded queue
processor... The results are most likely better using a (properly written)
queue, rather than IPC.
Mike
-----Ursprüngliche Nachricht-----
Von: Gussimulator [mailto:[EMAIL PROTECTED]
Gesendet: Mittwoch, 12. Juli 2006 19:47
An: sqlite-users@sqlite.org
Betreff: Re: [sqlite] Problems with Multi-Threaded Application.
Yes, in theory.
However, when about 100 queries are fired in a second, only a few get the
data populated..
I can not tell when to start or end the transactions, because events are
fired from a third-party system. So I used a timer, set to 5 seconds.. then
tried with 10 seconds, got the same result anyway (timer to a procedure that
would commit and begin transaction).
From 100 events about 30 were "processed".
About the "cant read while writing", how to avoid this?, I cant stop my
system while using the database. There would be no point on having a
database then.
----- Original Message -----
From: "Jay Sprenkle" <[EMAIL PROTECTED]>
To: <sqlite-users@sqlite.org>
Sent: Wednesday, July 12, 2006 12:59 PM
Subject: Re: [sqlite] Problems with Multi-Threaded Application.
On 7/12/06, Gussimulator <[EMAIL PROTECTED]> wrote:
Hello,
I'm currently using SQLite3 on my multi-threaded software.
I have tried several ways for dealing with my issue, however, I came to
the conclusion that there must be some trick I havent been told of.
It wasn't clear to me when I started that you can have as many readers as
you
want, but only one process may write to the database AND no other process
may read it while you are writing. If you use transactions and retry
when the database is locked it works fine and no data will be lost.
--
SqliteImporter and SqliteReplicator: Command line utilities for Sqlite
http://www.reddawn.net/~jsprenkl/Sqlite
Cthulhu Bucks!
http://www.cthulhubucks.com
