Re: persistent DB connections (was: RE: modular database backends)

[Milan Zamazal]

>>>>> "DB" == Dirk Bergstrom <address@hidden> writes:

    DB> 1) keep the current model, adding a separate, persistent,
    DB> "database daemon".  each connection would spawn a new instance
    DB> of gnatsd, which would connect to the database-daemon as needed.
    DB> i happened across sqlrelay
    DB> (http://www.firstworks.com/sqlrelay.html), a GPLed package which
    DB> appears to do just what's needed for the database daemon.

Since the addition the modular database backends feature would allow
this automatically, there'll be nothing to stop you doing this once it
is implemented.

    DB> 2) a persistent daemon that handles setting up the connection to
    DB> the client, and holds open a connection (or several connections)
    DB> to the database.  as new requests come in, the daemon would fork
    DB> off a child to handle each one, up to some preset limit.

I can imagine a very busy BTS where performance problems can arise.  If
you can *prove* that the overhead of reading configuration is a
significant part of the performance problem, I'll consider the
possibility of making a persistent daemon.

    DB> 3) something like apache -- a master process forks several
    DB> persistent daemons, which take turns handling connections.  each
    DB> child daemon holds a database connection, and services many
    DB> requests before shutting down.

IMHO unnecessarily complicated:

>>>>> "PN" == Peter Novodvorsky <address@hidden> writes:

    PN> Other approaches are good, but hey, do some BTS's handle more
    PN> then 10 connections at time? Really?

AOL!

Regards,

Milan Zamazal

-- 
  _/_\_/_  o     _\_/_\_  o     _/_\_/_  o     _\_/_\_  o    BEWARE!
-<_|_|_|_><--  -<_|_|_|_><--  -<_|_|_|_><--  -<_|_|_|_><--   *Bugs* are
   / \ /   o      \ / \   o      / \ /   o      \ / \   o     approaching!