On Thu, 15 Apr 2004, Andrew Piskorski wrote:
>On Thu, Apr 15, 2004 at 02:16:01PM +0100, Christian Smith wrote:
>> Right tool for the job. Multiple writers has client/server database
>> written all over it. KISS.
>
>No, not true, at least not when the multiple writers are all threads
>within one single process, which appears to be the common case for
>people who'd like greater concurrency in SQLite.
SQLite is an embedded database engine, which I guess is it's main use
(I'm using it at my place to implement a package management tool) and
the desired concurrency from what I gather on the list is read access
while writing, not multiple writers.
>
>Also, if multiple writers worked well for the one-process many-threads
>case, then if you wished you could write a small multi-threaded
>client/server database using SQLite as the underlying storage engine.
>As things stand now, the concurrency limitations mean there isn't much
>point to doing that.
But why re-invent the wheel. There are plenty of client/server databases
that support concurrent writes.
>
>Simplicity however, is of course an important concern.
Absolutely, that's my main point. I'm all for the concurrent
readers/writer, but multiple writers is a whole new ball game, probably
best left to the big boys.
Cheers,
Christian
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
