Hello,
Right now I'm using WAL mode with a single writer, and many readers.
At the moment, each reader is opening its own database connection.
As you can imagine, this is quite expensive.
Instead of maintaining a pool of sqlite connections, I'd like to move every
thread to share the same
-connection. So yes, SELECT will be a part of
transaction and you won't be able to commit or rollback the
transaction until all SELECT statements are reset or finalized.
Pavel
On Wed, Jan 25, 2012 at 1:02 PM, Erik Fears str...@strtok.net wrote:
Hello,
Right now I'm using WAL mode
I've got a WAL database with only readers right now. I'm opening and close
the database
at pretty rapid rate, and usually have about 100 connections open at a
time. I'm
using prepared statements for SELECTS and I'm pretty sure I'm finalizing
the statements.
After a while I start getting back
ideal, and plan to move to having less connections
or using a pool, but I still don't understand why this would be occurring
with WAL.
--erik
On Wed, Jan 25, 2012 at 5:39 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Jan 25, 2012 at 8:01 PM, Erik Fears str...@strtok.net wrote:
I've got a WAL
, Simon Slavin slav...@bigfraud.org wrote:
On 29 Sep 2010, at 8:20pm, Erik Fears wrote:
-C++ with 3 threads. One of them a write thread, one a main reader
thread,
and one a diagnostic reader thread
Does each thread open the database independently, or are you passing the
same handle from
sqlite-users,
Here's my test environment:
-RHEL 5 on a vmware server (trying to move this to ESX)
-C++ with 3 threads. One of them a write thread, one a main reader thread,
and one a diagnostic reader thread
-journal-mode=WAL
-no change to default synchronization mode
The write thread is
On 09/18/2010 01:45 PM, Erik Fears wrote:
but I've found that during a write transaction readers are locked from
reading the database.
I suggest reading the following two pages:
http://www.sqlite.org/lockingv3.html
http://www.sqlite.org/wal.html
Roger
-BEGIN PGP SIGNATURE
sqlite-users,
I've got a multi-threaded daemon that's inserting large batches into a table
that looks like this:
CREATE TABLE list_node (key INTEGER PRIMARY KEY, name TEXT UNIQUE, list
INT);
There's one writer thread, and one reader thread. Each thread would have its
own db object.
The very
