[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: persistent DB connections (was: RE: modular database backends )
From: |
Dirk Bergstrom |
Subject: |
RE: persistent DB connections (was: RE: modular database backends ) |
Date: |
Thu, 31 May 2001 16:50:37 -0700 |
i, too, am inclined towards #3, but it does require rather a lot of
re-engineering. under the current setup, gnatsd generally runs for only one
"transaction" (a search, a pr-edit, one gnatsweb hit, etc.). turning it
into a persistent daemon would, to put it nicely, help us discover any
hidden memory leaks.
furthermore, while gnatsd does have the RSET command ("reset internal
settings to initial startup"), it doesn't have any of the other mechanisms
necessary to a persistent daemon. i'm sure the code is readily available,
but it's not trivial to get everything working, stable, and leak-free...
--
Dirk Bergstrom address@hidden
____________________________________________
Juniper Networks Inc., Engineering Web Guru
Tel: 408.745.3182 Fax: 408.745.8905
> -----Original Message-----
> From: Michael Richardson [mailto:address@hidden
> Sent: Wednesday, May 30, 2001 9:09 AM
> To: Dirk Bergstrom
> Subject: Re: persistent DB connections (was: RE: modular database
> backends)
>
>
>
> You should put the database connection in gnatsd.
> It does not have to be spawned from inetd.
>
> #3 is where you should go.
>
> Canadian Commuter Challenge Project -- GNU Potato Caboose
> Michael Richardson, Sandelman Software Works, Ottawa, ON
> EMAIL: address@hidden
> for help, email or page at 1-866-231-8608
>
>
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- RE: persistent DB connections (was: RE: modular database backends ),
Dirk Bergstrom <=