On 7/22/07, James Mills <[EMAIL PROTECTED]> wrote:
On Sun, Jul 22, 2007 at 04:49:45AM -0700, Trevor Talbot wrote:
> Okay. Well, for most of the client/server databases, they already
> have an event model to piggyback on: network I/O. Since sqlite is
> embedded, it doesn't have one to use, so you have to roll your own.
> Many people just dedicate a thread to sqlite work, and pass messages
> back and forth to other threads using whatever method fits in with the
> rest of their application.
Would it seem reasonable then to write an sqlite server ?
Some people do that; there should be some examples and info in the
contrib and wiki parts of the web site. At this point you should make
sure sqlite is really appropriate for what you want to do, though:
http://sqlite.org/whentouse.html
A separate app with say an XML-RPC interface or similar ?
That sounds like quite a bit of overhead, but yes.
With other RDBMS such as MySQL, Oracle, FireBird, Postgresql
they more or less should support asyncronous queries right ?
Yes. You can browse this part of the PostgreSQL docs to get an idea
of the general model they use:
http://www.postgresql.org/docs/8.2/interactive/libpq-async.html
Embedded Firebird may be a special case, but IIRC it creates its own
threads internally. If you're looking for something with more
capability than sqlite but still easily distributable, that'd be my
next stop.
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
