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.


     X                           - AGAINST MS ATTACHMENTS
    / \

To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to