At some point shared usage of a single resource involves some form of
synchronization. If you use Sqlite the you need to add that capability
somehow. Sqlite lets you use file locks fairly simply for that purpose
if that suits your application.
An alternative is to use something like PostgreSQL or Oracle which
incorporate the extra layers of software but, ipso facto, lack the
simplicity of Sqlite.
The problem is not so strange, as Dr Hipp points out. Using Sqlite as a
shared resource is just like using a file as a shared resource. If you
take his advice that Sqlite is not a replacement for DB/2 or Oracle but
a replacement for fopen you understand the problem.
We find Sqlite to be a remarkable tool because it implements either a
small embedded database or becomes part of a lightweight implementation
of a special purpose multiple user database where the resource sharing
is tailored to the application and the overhead of an enterprise level
DBMS is thereby avoided.
David Gewirtz wrote:
Those suggestions are great. For something like log analysis, there's no
problem either reading in log file tails ever so often or queuing up a
single thread to give more real-time access. I think I'm leaning towards a
more real-time view, but I might take the tail option if it codes easier.
On the topic of threads, though, this does open a pile of other "running
behind a Web server" sort of operations:
* To keep a db of user authentication data in an SQLite db, users will need
some level of real-time response to logins
* To keep a db of, say, a discussion forum, user posts will need to be
written and made available in realish-time
* To update Web pages dynamically with information populated from a user's
preference or users' usage patterns, the page will need to be generated in
real time
And each of these interactions with the server will occur with different
user sessions in different threads. Can SQLite be used to build applications
that do the operations above? Do I need to do some single-thread queue
structure for each approach?
I'd love some guiding thoughts on these things to help understand how to
really approach the problem.
Thanks!
-- David
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
