Re: [sqlite] One more SQLite threading question
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 is right that, it works. How would multiple threads be faster than a single one when you are accessing a single resource? Assumably the thread that is accessing the database either spends some time gathering data to write or processing data it read. The single resource isn't in use during that time. I just notice that threading is often misunderstood. It is a way of sharing resources, not of making single resources, like a CPU or a database handler using a single disk drive operate faster. This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 a seperate Database connection. The locking occurs as a part of the Pager locking which is whole file for the duration of the transaction. AFAIK, the shared cache API is pretty worthless as the only way to implement this is through a single "server" thread. 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. One thing that Other database engines do is allow read and writes to occur without blocking. That is a Reader never blocks a writer and a Writer never blocks a reader. SQLITE does not do this, Only a single writer or Multiple readers, but not both concurrently. I'm not trying to pick on sqlite, just pointing out that it really doesn't perform multi threading or even conncurrent access very well in a read/write environment. Read Only, its great. Single threaded Read/Write ... Very good as well. Regards, Ken Doug Nebeker <[EMAIL PROTECTED]> 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 is right that, it works. How would multiple threads be faster than a single one when you are accessing a single resource? Assumably the thread that is accessing the database either spends some time gathering data to write or processing data it read. The single resource isn't in use during that time. This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] One more SQLite threading question
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-cache actually decreases concurrency. A smart embedded server (smarter than test_server.c) might be able to manage query execution to work around this. If the process does not require multiple logical connections, or saving memory and extra file-system reads is not an issue in your environment, shared-cache mode will likely do nothing for you. Dan. > I just don't see where any concurrency is gained. Sure maybe some > memory savings. But I must be brain dead, because I don't see how it > could improve concurrency given that a single thread is used to > perform db access. And all clients are queued and blocked upon the > single threads message queue. > > Thanks, > Ken > > > > > Dan Kennedy <[EMAIL PROTECTED]> wrote: > > 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 > transaction context). It's meant to reduce IO and memory > usage in the case that a process opens more than one > connection to the same database file. > > It's quite a specialised feature. Only really useful > if you are implementing an embedded server. > > Dan > > > > > One thing that Other database engines do is allow read and > writes to occur without blocking. That is a Reader never > blocks a writer and a Writer never blocks a reader. SQLITE > does not do this, Only a single writer or Multiple readers, > but not both concurrently. > > > > I'm not trying to pick on sqlite, just pointing out that it > really doesn't perform multi threading or even conncurrent > access very well in a read/write environment. Read Only, its > great. Single threaded Read/Write ... Very good as well. > > > > Regards, > > Ken > > > > > > > > > > > > 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 > > is > > > > right that, it works. > > > > > >How would multiple threads be faster than a single one when > you are > > accessing a single resource? > > > > Assumably the thread that is accessing the database either > spends some > > time gathering data to write > > or processing data it read. The single resource isn't in use > during > > that time. > > > > This email was sent to you by Reuters, the global news and > information company. > > To find out more about Reuters visit www.about.reuters.com > > > > Any views expressed in this message are those of the > individual sender, > > except where the sender specifically states them to be the > views of Reuters Limited. > > > > Reuters Limited is part of the Reuters Group of companies, > of which Reuters Group PLC is the ultimate parent company. > > Reuters Group PLC - Registered office address: The Reuters > Building, South Colonnade, Canary Wharf, London E14 5EP, > United Kingdom > > Registered No: 3296375 > > Registered in England and Wales > > > > > > > > > > - > > To unsubscribe, send email to > [EMAIL PROTECTED] > > > > - > > > > > > > > - > To unsubscribe, send email to > [EMAIL PROTECTED] > > - > > - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] One more SQLite threading question
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't see how it could improve concurrency given that a single thread is used to perform db access. And all clients are queued and blocked upon the single threads message queue. Thanks, Ken Dan Kennedy <[EMAIL PROTECTED]> wrote: > 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 transaction context). It's meant to reduce IO and memory usage in the case that a process opens more than one connection to the same database file. It's quite a specialised feature. Only really useful if you are implementing an embedded server. Dan > One thing that Other database engines do is allow read and writes to occur > without blocking. That is a Reader never blocks a writer and a Writer never > blocks a reader. SQLITE does not do this, Only a single writer or Multiple > readers, but not both concurrently. > > I'm not trying to pick on sqlite, just pointing out that it really doesn't > perform multi threading or even conncurrent access very well in a read/write > environment. Read Only, its great. Single threaded Read/Write ... Very good > as well. > > Regards, > Ken > > > > > > 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 > is > > > right that, it works. > > > >How would multiple threads be faster than a single one when you are > accessing a single resource? > > Assumably the thread that is accessing the database either spends some > time gathering data to write > or processing data it read. The single resource isn't in use during > that time. > > This email was sent to you by Reuters, the global news and information > company. > To find out more about Reuters visit www.about.reuters.com > > Any views expressed in this message are those of the individual sender, > except where the sender specifically states them to be the views of Reuters > Limited. > > Reuters Limited is part of the Reuters Group of companies, of which Reuters > Group PLC is the ultimate parent company. > Reuters Group PLC - Registered office address: The Reuters Building, South > Colonnade, Canary Wharf, London E14 5EP, United Kingdom > Registered No: 3296375 > Registered in England and Wales > > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] One more SQLite threading question
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 locking which is whole file for the duration of the transaction. AFAIK, the shared cache API is pretty worthless as the only way to implement this is through a single "server" thread. 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. One thing that Other database engines do is allow read and writes to occur without blocking. That is a Reader never blocks a writer and a Writer never blocks a reader. SQLITE does not do this, Only a single writer or Multiple readers, but not both concurrently. I'm not trying to pick on sqlite, just pointing out that it really doesn't perform multi threading or even conncurrent access very well in a read/write environment. Read Only, its great. Single threaded Read/Write ... Very good as well. Regards, Ken Doug Nebeker <[EMAIL PROTECTED]> 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 is > > right that, it works. > >How would multiple threads be faster than a single one when you are accessing a single resource? Assumably the thread that is accessing the database either spends some time gathering data to write or processing data it read. The single resource isn't in use during that time. This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales - To unsubscribe, send email to [EMAIL PROTECTED] -
RE: [sqlite] One more SQLite threading question
> > 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 > > right that, it works. > >How would multiple threads be faster than a single one when you are accessing a single resource? Assumably the thread that is accessing the database either spends some time gathering data to write or processing data it read. The single resource isn't in use during that time. This email was sent to you by Reuters, the global news and information company. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Limited. Reuters Limited is part of the Reuters Group of companies, of which Reuters Group PLC is the ultimate parent company. Reuters Group PLC - Registered office address: The Reuters Building, South Colonnade, Canary Wharf, London E14 5EP, United Kingdom Registered No: 3296375 Registered in England and Wales - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Yeah, in the face of "mostly" I was guaranteed to assume it should still be avoided (I may need to not make many restrictions where its used). Thanks -Original Message- From: Dan Kennedy <[EMAIL PROTECTED]> Date: Fri, 18 May 2007 13:31:10 To:sqlite-users@sqlite.org Subject: Re: [sqlite] One more SQLite threading question On Thu, 2007-05-17 at 18:26 -0400, Martin Gentry wrote: > Can you be a bit more specific? :-) I ask because this is immediately > relevant to some code I'm writing today, and have been operating on the > understanding that I should honour the restriction. I'm fine with honouring > the restriction if required, but it might make my life easier if I don't > have to. The current official position, as I understand it, is that you can pass handles between threads. There are no known reasons that this will not work. But it's been a source of bugs in the past, and I personally wouldn't risk it if I had the choice. Especially if I thought the code could be deployed with a variety of different OS's or kernel versions. But that's just an opinion. Tricky things, threads. Dan. > - Original Message - > From: <[EMAIL PROTECTED]> > To: <sqlite-users@sqlite.org> > 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#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 > > resulting database handle off to another thread to use. This restriction > > is > > due to goofy design decisions (bugs?) in the way some threading > > implementations interact with file locks." > > > > That restriction is due to bugs in GLIBC or maybe the Linux Kernel > (I'm not sure which) which have been resolved. And for that matter, > more recent versions of SQLite work around the bugs even if they > are there. So you can mostly ignore this now. Mostly. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
On Thu, 2007-05-17 at 18:26 -0400, Martin Gentry wrote: > Can you be a bit more specific? :-) I ask because this is immediately > relevant to some code I'm writing today, and have been operating on the > understanding that I should honour the restriction. I'm fine with honouring > the restriction if required, but it might make my life easier if I don't > have to. The current official position, as I understand it, is that you can pass handles between threads. There are no known reasons that this will not work. But it's been a source of bugs in the past, and I personally wouldn't risk it if I had the choice. Especially if I thought the code could be deployed with a variety of different OS's or kernel versions. But that's just an opinion. Tricky things, threads. Dan. > - Original Message - > From: <[EMAIL PROTECTED]> > To: <sqlite-users@sqlite.org> > 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#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 > > resulting database handle off to another thread to use. This restriction > > is > > due to goofy design decisions (bugs?) in the way some threading > > implementations interact with file locks." > > > > That restriction is due to bugs in GLIBC or maybe the Linux Kernel > (I'm not sure which) which have been resolved. And for that matter, > more recent versions of SQLite work around the bugs even if they > are there. So you can mostly ignore this now. Mostly. > > -- > D. Richard Hipp <[EMAIL PROTECTED]> > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > > > > - > To unsubscribe, send email to [EMAIL PROTECTED] > - > - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 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 methods? My guess that it should work well then, but I haven't tried it myself... 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 right that, it works. How would multiple threads be faster than a single one when you are accessing a single resource? - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
Can you be a bit more specific? :-) I ask because this is immediately relevant to some code I'm writing today, and have been operating on the understanding that I should honour the restriction. I'm fine with honouring the restriction if required, but it might make my life easier if I don't have to. - Original Message - From: <[EMAIL PROTECTED]> To: <sqlite-users@sqlite.org> 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#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 resulting database handle off to another thread to use. This restriction is due to goofy design decisions (bugs?) in the way some threading implementations interact with file locks." That restriction is due to bugs in GLIBC or maybe the Linux Kernel (I'm not sure which) which have been resolved. And for that matter, more recent versions of SQLite work around the bugs even if they are there. So you can mostly ignore this now. Mostly. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
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#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 > resulting database handle off to another thread to use. This restriction is > due to goofy design decisions (bugs?) in the way some threading > implementations interact with file locks." > That restriction is due to bugs in GLIBC or maybe the Linux Kernel (I'm not sure which) which have been resolved. And for that matter, more recent versions of SQLite work around the bugs even if they are there. So you can mostly ignore this now. Mostly. -- D. Richard Hipp <[EMAIL PROTECTED]> - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 resulting database handle off to another thread to 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: <sqlite-users@sqlite.org> Sent: Thursday, May 17, 2007 4:18 PM Subject: Re: [sqlite] One more SQLite threading question 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 statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... 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 right that, it works. - To unsubscribe, send email to [EMAIL PROTECTED] - - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 statement #2 while B is still executing #1. Have you tried using Mutex or some other way to prevevent really simultaneous calling of SQLite methods? My guess that it should work well then, but I haven't tried it myself... 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 right that, it works. - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 methods? My guess that it should work well then, but I haven't tried it myself... Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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. * signed 64-bit integer column value support. * automatic per-thread connection creation. * string_reference and blob_reference binding support (minimizes copies and memory allocations, important in the client-side game industry). * precompiled statement support with execution states to support binding & result sets. Eventually it will be more aware of sqlite3 features currently exposed via PRAGMA commands. But at the moment, it works well enough for me. andy On 5/16/07, Ed Pasma <[EMAIL PROTECTED]> wrote: 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 rest, including sqlite3_step. 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. So the experimental conclusion is that this won't work. But this applies only to the pipelining idea. The serializing to use a single connection may still offer an interesting new locking model. Regards, Ed Pasma Op 14-mei-2007, om 13:04 heeft Jiri Hajek het volgende geschreven: > Hello, > > I have tried to search all the documentation about threading in > SQLite, but > I'm still somewhat confused. > > It's often suggested to create a pool of sqlite3 structures, but > what if I > would like to have only only sqlite3 connection and serialize all > the DB > operations to one thread (name it 'A') that would prepare and > execute all > the queries. I guess that this would work well... > > 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. So > my scenario is: > > 1. Thread B wants to open a query 'SELECT * FROM Tbl1' > 2. Thread A is used to prepare the query 'SELECT * FROM Tbl1' using > sqlite3_prepare16_v2() and using the same sqlite3 DB connection as for > possibly some other running SQL statements. > 3. Thread B now repeatedly calls sqlite3_step(), > sqlite3_column_text16() and > similar functions in order to get all rows from DB. > 4. Thread A is used to call sqlite3_finalize() on the openned query. > > So my questions are: > a. Would the code described above work. > b. In step 3., do I have to somehow make sure that calls to > sqlite3_step() > don't interfere with other SQLite processing in thread A, e.g. by > Windows > CriticalSections? Is anything like this also needed for > sqlite3_column_text16()? > > Thanks for any explanation, > Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
Re: [sqlite] One more SQLite threading question
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 rest, including sqlite3_step. 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. So the experimental conclusion is that this won't work. But this applies only to the pipelining idea. The serializing to use a single connection may still offer an interesting new locking model. Regards, Ed Pasma Op 14-mei-2007, om 13:04 heeft Jiri Hajek het volgende geschreven: Hello, I have tried to search all the documentation about threading in SQLite, but I'm still somewhat confused. It's often suggested to create a pool of sqlite3 structures, but what if I would like to have only only sqlite3 connection and serialize all the DB operations to one thread (name it 'A') that would prepare and execute all the queries. I guess that this would work well... 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. So my scenario is: 1. Thread B wants to open a query 'SELECT * FROM Tbl1' 2. Thread A is used to prepare the query 'SELECT * FROM Tbl1' using sqlite3_prepare16_v2() and using the same sqlite3 DB connection as for possibly some other running SQL statements. 3. Thread B now repeatedly calls sqlite3_step(), sqlite3_column_text16() and similar functions in order to get all rows from DB. 4. Thread A is used to call sqlite3_finalize() on the openned query. So my questions are: a. Would the code described above work. b. In step 3., do I have to somehow make sure that calls to sqlite3_step() don't interfere with other SQLite processing in thread A, e.g. by Windows CriticalSections? Is anything like this also needed for sqlite3_column_text16()? Thanks for any explanation, Jiri - To unsubscribe, send email to [EMAIL PROTECTED] -
[sqlite] One more SQLite threading question
Hello, I have tried to search all the documentation about threading in SQLite, but I'm still somewhat confused. It's often suggested to create a pool of sqlite3 structures, but what if I would like to have only only sqlite3 connection and serialize all the DB operations to one thread (name it 'A') that would prepare and execute all the queries. I guess that this would work well... 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. So my scenario is: 1. Thread B wants to open a query 'SELECT * FROM Tbl1' 2. Thread A is used to prepare the query 'SELECT * FROM Tbl1' using sqlite3_prepare16_v2() and using the same sqlite3 DB connection as for possibly some other running SQL statements. 3. Thread B now repeatedly calls sqlite3_step(), sqlite3_column_text16() and similar functions in order to get all rows from DB. 4. Thread A is used to call sqlite3_finalize() on the openned query. So my questions are: a. Would the code described above work. b. In step 3., do I have to somehow make sure that calls to sqlite3_step() don't interfere with other SQLite processing in thread A, e.g. by Windows CriticalSections? Is anything like this also needed for sqlite3_column_text16()? Thanks for any explanation, Jiri
