Limiting database connections?

[dsal...@gmail.com]

I ran out of database connections today. I'd like to prevent this in a
way other than increasing my database connections.

How does this work in Django? I'd like more reuse and all. Coming
from a java background, it's typical for me to configure my application
to use very few connections (often just one) for something similar to
what I'm doing with Django.

I've got three apps now, with three different DB configs (three sites),
each with its own admin site. It's unclear to me how much of this
stuff can be shared.

Any tips?

[Jason McBrayer]

dsal...@gmail.com wrote:

>I ran out of database connections today. I'd like to prevent this in a
>way other than increasing my database connections.
>
>

Jonpy (jonpy.sf.net) has a nice and simple dbpool module. I'm not sure
how much work it would take to get django to use it, however.

[Ksenia Marasanova]

2005/8/12, dsal...@gmail.com <dsal...@gmail.com>:

I believe it's convinient in Python frameworks to create your database
connection when the application starts and then re-use it within one
process / application (by attaching the instance to the main publisher
somehow) . If you want to share connection between apps, some external
pool tool is probably needed (jonpy was already mentioned, there is
also Postgres-specific pgpool...)

--
Ksenia

[Jacob Kaplan-Moss]

I just today ran across sqlrelay (http://sqlrelay.sourceforge.net/)
which looks *extremely* promising for this type of use. Does anyone
have any experience with it, and is there any interest in me writing
a sqlrelay backend?

Jacob

[Matthew Marshall]

On Friday 12 August 2005 08:14 pm, Jacob Kaplan-Moss wrote:
> I just today ran across sqlrelay (http://sqlrelay.sourceforge.net/)
> which looks *extremely* promising for this type of use. Does anyone
> have any experience with it, and is there any interest in me writing
> a sqlrelay backend?
>
> Jacob

From this quote on the sqlrelay site...

"""
An application coded using another database's native client API may be able to
use SQL Relay without modification. SQL Relay provides drop-in replacement
libraries for:
* MySQL * PostgreSQL
"""

... a sqlrelay backend might only be a few lines!

MWM

[Jacob Kaplan-Moss]

On Aug 12, 2005, at 4:36 PM, Matthew Marshall wrote:

> From this quote on the sqlrelay site...
>
> """
> An application coded using another database's native client API may
> be able to
> use SQL Relay without modification. SQL Relay provides drop-in
> replacement
> libraries for:
> * MySQL * PostgreSQL
> """
>
> ... a sqlrelay backend might only be a few lines!
>

Those are C libraries, unfortunately... but there is a Python DB-API
layer, so it shouldn't be too hard.

Jacob

[Maniac]

Jacob Kaplan-Moss wrote:

> I just today ran across sqlrelay (http://sqlrelay.sourceforge.net/)
> which looks *extremely* promising for this type of use. Does anyone
> have any experience with it, and is there any interest in me writing
> a sqlrelay backend?

We did :-). We tried to squeze it between PHP and Oracle. PHP was
written in MySQL-style, opening DB connection whenever it felt it might
require some tiny chunk of data. And this bit us hard when we gained a
bit more users and learned that opening connection in Oracle is not
exactly cheap operation...

Some sad history aside, we tried SQLRelay following recomendation from
Oracle's OSDN forums but it didn't work out very well. Under havy load
it sometimes just SEGFAULTed without any explanation in logs (oh, those
verbose logs where single event that happend to use several physical
connection was spread across several files with helpful names like
2684). We considered it to be not acceptable for a production server.

To be honest, may be those problems were related to PHP or Oracle's part
of SQLRelay, and won't affect other environments, and it was like a year
ago, so may be it was fixed since... But now for me it doesn't look very
promising.

[Jeremy Dunck]

On 8/12/05, Maniac <Man...@softwaremaniacs.org> wrote:
> To be honest, may be those problems were related to PHP or Oracle's part
> of SQLRelay, and won't affect other environments, and it was like a year
> ago, so may be it was fixed since... But now for me it doesn't look very
> promising.

It's clearly being actively developed, but I couldn't speak to the
specific issue you had. I'm attaching the latest change log, if it
helps.

[dsal...@gmail.com]

SQLRelay seems like an acceptable option. If this is the recommended
way to do things, is any work being done on making it work?