The traditional CGI approach is to open and close the database for each
transaction. If you build your own threaded server to avoid that it
does not make sense to continue the open and close situation.
Opening and closing the DB is not an enormous overhead, but is ugly if
your clients are using the same data because it destroys cacheing. I
suspect that it is morally and ethically neutral, just ugly :-).
If you have a multi-threaded server using a single user DB like Sqlite
you can dedicate a thread to handle each database and maintain the DB
open while the server runs. You then get optimal performance and avoid
locking and contention problems. You can feed the the DB thread with a
FIFO buffer sync'd on events, which are an efficient mechanism in a
threaded environment.
What language are you using? Certain language environments would make
implementing the server clumsy.
You will also find that Win32 threads and pthreads operate similarly, so
you can easily make your program work on both Windows and Linux.
David Gewirtz wrote:
In my ongoing attempt to find the best approach for integrating SQLite into
a threaded Web-serving environment, I came upon a truly crude kludge, and I
wanted to know if it's bad from an SQLite architectural standpoint. I know
it's bad morally and ethically.
Basically, is it bad if I decide to open and close the same database a LOT?
For example, rather than opening a database when the server boots and
keeping it open for the duration, is it bad if I open it for every query and
close it right away? I'd set some sort of open-semaphore so multiple threads
wouldn't open it at once, but then, even though different threads would be
working on the database, they'd each have their own id.
The only gotcha is the bazillion times the db's opened and closed.
So, what do you think? Just poor programming or dangerous to do? Also, is
there a ton of overhead on open or close?
Thanks,
David
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
