On 3/20/07, Jakub Ladman <[EMAIL PROTECTED]> wrote:
Dne úterý 20 březen 2007 12:42 Igor Tandetnik napsal(a):
> Rafi Cohen <[EMAIL PROTECTED]> wrote:
> > 1. Should I open the database explicitly in the amin part and also in
> > the thread?
>
> In my experience, SQLite works best when every thread opens its own
> connection.
How should I understand it?
It is faster? Much secure or what?
I have multithreaded program, where some threads are inserting data into
tables (in random moments), two of them are retrieving subsets of data to
send it via udp protocol over internet in short data length, and one thread
operates as terminal for human users, where (single) user can fed sql
statements and retrieve data in human readable format.
The architecture looks like this: Single thread locks a common mutex just
before and then calls an sqlite api, when it receives excepted data, the
mutex is unlocked.
Do you think that is there a better method?
Thank You
Jakub Ladman
-
To unsubscribe, send email to [EMAIL PROTECTED]
-
SQLite can support multiple readers to the same database, so the
common mutex will be a bottle neck if two separate threads want to
simply do reads from the database. In an application I am writing, I
was doing the same approach as you, then I switch to using a separate
database pointer per thread, and I noticed that my code just looked
cleaner (since when I needed to open a database, I just created an
instance of an sqlite wrapper class I wrote, and did not have to worry
about sharing the mutex or any other synchronization problems).
Note, that if one thread performs a write the database will be locked,
so other threads may stall, if you chose to use multiple SQLITE db
pointers, make sure you check your sqlite_steps/exec's for the return
condition SQLITE_BUSY (and/or SQLITE_LOCKED).
In general if a library multithreads well (which in my opinion sqlite
3 does) then why not take advantage of it... Instead of trying to
serialize concurrent processes in your code.
Let me know how it works.
