On Wed, 26 Jul 2006 16:02:00 -0500, Dennis Jenkins wrote:
>[EMAIL PROTECTED] wrote:
>> It has been suggested that I add a mutex to every SQLite
>> database connection. This would cause access to a database
>> connection to automatically serialize even when two or more
>> threads try to use that
Jay Sprenkle wrote:
On 7/26/06, John Stanton <[EMAIL PROTECTED]> wrote:
>
> Almost a "plug-in" serialization organization. I don't think I've ever
> seen anyone do it that way, but that might be really valuable.
> The embedded software guys would just love it.
We had an ISAM product which work
On Wed, Jul 26, 2006 at 02:32:58PM +, [EMAIL PROTECTED] wrote:
> It has been suggested that I add a mutex to every SQLite
> database connection. This would cause access to a database
> connection to automatically serialize even when two or more
> threads try to use that connection at once, thu
[EMAIL PROTECTED] wrote:
It has been suggested that I add a mutex to every SQLite
database connection. This would cause access to a database
connection to automatically serialize even when two or more
threads try to use that connection at once, thus preventing
problems such as the above.
The do
On 7/26/06, John Stanton <[EMAIL PROTECTED]> wrote:
>
> Almost a "plug-in" serialization organization. I don't think I've ever
> seen anyone do it that way, but that might be really valuable.
> The embedded software guys would just love it.
We had an ISAM product which worked after that fashion.
Jay Sprenkle wrote:
On 7/26/06, John Stanton <[EMAIL PROTECTED]> wrote:
Jay Sprenkle wrote:
>> > Will the mutex replace file locking for database access control?
>> >
>>
>> No. A mutex only works within a single process.
>
>
> I was thinking it might make a good compile time option.
> If you a
On 7/26/06, John Stanton <[EMAIL PROTECTED]> wrote:
Jay Sprenkle wrote:
>> > Will the mutex replace file locking for database access control?
>> >
>>
>> No. A mutex only works within a single process.
>
>
> I was thinking it might make a good compile time option.
> If you aren't going to access
Jay Sprenkle wrote:
> Will the mutex replace file locking for database access control?
>
No. A mutex only works within a single process.
I was thinking it might make a good compile time option.
If you aren't going to access the database from multiple machines then
the mutex could replace fil
[EMAIL PROTECTED] wrote:
"Rob Richardson" <[EMAIL PROTECTED]> wrote:
I found the spot where I was telling the two threads to use the same
database pointer instead of running on separate ones. Once I fixed
that, it works.
It has been suggested that I add a mutex to every SQLite
database con
On 7/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
It has been suggested that I add a mutex to every SQLite
database connection. This would cause access to a database
connection to automatically serialize even when two or more
threads try to use that connection at once, thus preventing
pr
Jay Sprenkle wrote:
Why are two threads reading the same data?
Last != previous?
I read it as penultimate vs pre-penultimate data.
Martin
> Will the mutex replace file locking for database access control?
>
No. A mutex only works within a single process.
I was thinking it might make a good compile time option.
If you aren't going to access the database from multiple machines then
the mutex could replace file locking as an access
"Jay Sprenkle" <[EMAIL PROTECTED]> wrote:
> On 7/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> > "Rob Richardson" <[EMAIL PROTECTED]> wrote:
> > > I found the spot where I was telling the two threads to use the same
> > > database pointer instead of running on separate ones. Once I fixed
>
On 7/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
"Rob Richardson" <[EMAIL PROTECTED]> wrote:
> I found the spot where I was telling the two threads to use the same
> database pointer instead of running on separate ones. Once I fixed
> that, it works.
>
It has been suggested that I add a
"Rob Richardson" <[EMAIL PROTECTED]> wrote:
> I found the spot where I was telling the two threads to use the same
> database pointer instead of running on separate ones. Once I fixed
> that, it works.
>
It has been suggested that I add a mutex to every SQLite
database connection. This would ca
, July 26, 2006 9:49 AM
To: sqlite-users@sqlite.org
Subject: Re: [sqlite] Reading the same table from two threads
On 7/26/06, Rob Richardson <[EMAIL PROTECTED]> wrote:
> Jay,
>
> After the first thread, a graph will be displayed and the user can
start
> doing things on it while the
On 7/26/06, Rob Richardson <[EMAIL PROTECTED]> wrote:
Jay,
After the first thread, a graph will be displayed and the user can start
doing things on it while the next batch of data is being loaded.
Ah.
"Many readers" should work fine.
An access violation sounds like a bad pointer or a compile
: Re: [sqlite] Reading the same table from two threads
On 7/26/06, Rob Richardson <[EMAIL PROTECTED]> wrote:
> few milliseconds after the first one. I am getting an access
violation
> inside sqlite3.dll when the second thread calls sqlite3_prepare(). Am
I
> trying to do someth
Am 26.07.2006 um 14:43 schrieb Rob Richardson:
Greetings!
I am starting two threads in quick succession that read the same
table.
Each thread calls sqlite3_open(), so they are using separate database
pointers. The first thread asks for records recorded in the last 24
hours. The second t
On 7/26/06, Rob Richardson <[EMAIL PROTECTED]> wrote:
few milliseconds after the first one. I am getting an access violation
inside sqlite3.dll when the second thread calls sqlite3_prepare(). Am I
trying to do something I shouldn't?
Bugs aside, that should work. It doesn't sound like a very e
Greetings!
I am starting two threads in quick succession that read the same table.
Each thread calls sqlite3_open(), so they are using separate database
pointers. The first thread asks for records recorded in the last 24
hours. The second thread asks for records from the same table recorded
i
21 matches
Mail list logo
