Doug Nebeker wrote:
Yes I did the same experiment with a lock that made thread A wait
until B was finished. So actually only one thread can be active at
the time.
I don't see how the outcome of this experiment can be of any
interest, as there is no time reduction any longer. But your guess
You can get what you want right now. It is called PostgreSQL.
Ken wrote:
I would be interested in a version of SQLITE that handled threading in a much cleaner way. I have a need for a single process version that is threaded.
But, where SQLITE locking is concerned each thread is really like
On Fri, 2007-05-18 at 11:46 -0700, Ken wrote:
> Dan,
> Can you explain to me how within the context of the test_server.c code
> that the
> sqlite3_enable_shared_Cache will improve concurrency, for a single DB
> file access?
Others have pointed out in the past that in many cases
using a shared-cac
Dan,
Can you explain to me how within the context of the test_server.c code that
the
sqlite3_enable_shared_Cache will improve concurrency, for a single DB file
access?
I just don't see where any concurrency is gained. Sure maybe some memory
savings. But I must be brain dead, because I don'
> Which in that case whats the point of a shared cache?
> What is it shared against, since all threads must send
> data to the shared server anyways and none may access
> it concurrently.
The idea is to have a single cache shared accessed by
more than one logical connection (read: more than one
I would be interested in a version of SQLITE that handled threading in a much
cleaner way. I have a need for a single process version that is threaded.
But, where SQLITE locking is concerned each thread is really like a seperate
Database connection. The locking occurs as a part of the Pager
> > Yes I did the same experiment with a lock that made thread A wait
> > until B was finished. So actually only one thread can be active at
the time.
> > I don't see how the outcome of this experiment can be of any
> > interest, as there is no time reduction any longer. But your guess
is
> >
> - Original Message -
> From: <[EMAIL PROTECTED]>
> To:
> Sent: Thursday, May 17, 2007 5:01 PM
> Subject: Re: [sqlite] One more SQLite threading question
>
>
> "Martin Gentry" <[EMAIL PROTECTED]> wrote:
> > Just as an FYI on the threadin
L PROTECTED]>
> To:
> Sent: Thursday, May 17, 2007 5:01 PM
> Subject: Re: [sqlite] One more SQLite threading question
>
>
> "Martin Gentry" <[EMAIL PROTECTED]> wrote:
> > Just as an FYI on the threading ...
> > http://www.sqlite.org/capi3ref.html#sqlite
Ed Pasma wrote:
However, it would be too time consuming to serialize every call to
sqlite3_step(), so I wonder whether it can be called in another
thread.
This almost immediately raises
"library routine called out of sequence". It occurs as soon as the
processing of A and B overlap, that mea
if I don't
have to.
- Original Message -
From: <[EMAIL PROTECTED]>
To:
Sent: Thursday, May 17, 2007 5:01 PM
Subject: Re: [sqlite] One more SQLite threading question
"Martin Gentry" <[EMAIL PROTECTED]> wrote:
Just as an FYI on the threading ...
http://www.
"Martin Gentry" <[EMAIL PROTECTED]> wrote:
> Just as an FYI on the threading ...
> http://www.sqlite.org/capi3ref.html#sqlite3_open
>
> "The returned sqlite3* can only be used in the same thread in which it was
> created. It is an error to call sqlite3_open() in one thread then pass the
> resul
o use. This restriction is
due to goofy design decisions (bugs?) in the way some threading
implementations interact with file locks."
-martin
- Original Message -
From: "Ed Pasma" <[EMAIL PROTECTED]>
To:
Sent: Thursday, May 17, 2007 4:18 PM
Subject: Re: [sqlite]
However, it would be too time consuming to serialize every call to
sqlite3_step(), so I wonder whether it can be called in another
thread.
This almost immediately raises
"library routine called out of sequence". It occurs as soon as the
processing of A and B overlap, that means A is preparing
This almost immediately raises
"library routine called out of sequence". It occurs as soon as the
processing of A and B overlap, that means A is preparing statement #2
while B is still executing #1.
Have you tried using Mutex or some other way to prevevent really
simultaneous calling of SQLite m
I have recently encountered the same cross-thread library misuse bug, and
ended up re-implement a C++ wrapper to be thread-aware and thread-safe.
It's not yet feature complete, compared to CPPSQLite3DB, but it does have
several good enhancements:
* signed 64-bit integer parameter binding support.
Hello,
I have no inside-knowledge from SQLite, but I'am in the circumstance
to easily do this experiment. Hope I understand it right and that you
consider a sort of pipe-lining. Anyway, I started the two threads A
and B, and made A exclusively do all the sqlite3_prepare calls, and B
the r
17 matches
Mail list logo
