Re: Database pooling vs. persistent connections

Just FYI, in the DB2 backend for Django, we have exposed a custom database property PCONNECT and have defaulted it to true for a long time now. What this does is that it uses persistent connections that is supported by the DB2 Python driver (http://code.google.com/p/ibm-db/ wiki/APIs#ibm_db.pconnec

Re: Database pooling vs. persistent connections

On 02/18/2013 02:27 PM, Aymeric Augustin wrote: > Problem #1: Is it worth re-executing the connection setup at the beginning of > every request? > > The connection setup varies widely between backends: > - SQLite: none > - PostgreSQL: > https://github.com/django/django/blob/master/django/db/backe

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 23:30, Karen Tracey wrote: > Will persistent connections be able to ensure that "bad connections" (e.g. > those in state "current transaction is aborted, commands ignored until end of > transaction block") don't leak from one request to another? I'm calling connection.abor

Re: Database pooling vs. persistent connections

On Mon, Feb 18, 2013 at 5:33 PM, Alex Gaynor wrote: > As far as I know, the MySQL timeout time is configurable, and the default > is 8 hours. > Assuming this is what does: http://dev.mysql.com/doc/refman/5.0/en/server-system-variables.html#sysvar_wait_timeoutthat sounds right. I guess I have jus

Re: Database pooling vs. persistent connections

As far as I know, the MySQL timeout time is configurable, and the default is 8 hours. Alex On Mon, Feb 18, 2013 at 2:30 PM, Karen Tracey wrote: > Just a couple of random quick thoughts: > > Will persistent connections be able to ensure that "bad connections" (e.g. > those in state "current tra

Re: Database pooling vs. persistent connections

Just a couple of random quick thoughts: Will persistent connections be able to ensure that "bad connections" (e.g. those in state "current transaction is aborted, commands ignored until end of transaction block") don't leak from one request to another? MySQL, at least, will close a connection fro

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 14:47, Jacob Kaplan-Moss wrote: > This fix represents a cheap and easy performance improvement. Let's get it in. After working on a few iterations of the patch, I have identified two problems worth discussing. Problem #1: Is it worth re-executing the connection setup at th

Re: Is there a buildbot? Is there a waterfall? Do the tests pass against all backends?

> > > you can see the tests at http://ci.djangoproject.com/ -- currently Oracle > is untested cause it's a major pita to setup on ubuntu. > Thanks for the info. If anyone is interested, I get 11 failures and 5 errors on master against Oracle with ./runtests right now: ===

Re: Database pooling vs. persistent connections

On 18 févr. 2013, at 19:51, Michael wrote: > I was just alerted to this by the reopening of ticket #18135. My initial analysis is incomplete. I'll comment on the ticket in a few minutes. > I will argue, however, that the AWS use case is a reason we need this to be > an OPTION, not automatic.

Re: Database pooling vs. persistent connections

On Mon, Feb 18, 2013 at 2:21 PM, Carl Meyer wrote: > On 02/18/2013 12:17 PM, Michael wrote: > > On Mon, Feb 18, 2013 at 2:03 PM, Jacob Kaplan-Moss > > wrote: > > > > On Mon, Feb 18, 2013 at 1:51 PM, Michael > > wrote: > > > I w

Re: Database pooling vs. persistent connections

On 02/18/2013 12:17 PM, Michael wrote: > On Mon, Feb 18, 2013 at 2:03 PM, Jacob Kaplan-Moss > wrote: > > On Mon, Feb 18, 2013 at 1:51 PM, Michael > wrote: > > I will argue, however, that the AWS use case is a reason we need >

Re: Database pooling vs. persistent connections

On Mon, Feb 18, 2013 at 2:03 PM, Jacob Kaplan-Moss wrote: > On Mon, Feb 18, 2013 at 1:51 PM, Michael wrote: > > I will argue, however, that the AWS use case is a reason we need this to > be > > an OPTION, not automatic. > > Check out Aymeric's patch; it is indeed an option triggered by > DATABASE

Re: Database pooling vs. persistent connections

On Mon, Feb 18, 2013 at 1:51 PM, Michael wrote: > I will argue, however, that the AWS use case is a reason we need this to be > an OPTION, not automatic. Check out Aymeric's patch; it is indeed an option triggered by DATABASES[CONN_MAX_AGE]. Jacob -- You received this message because you are s

Re: Database pooling vs. persistent connections

I was just alerted to this by the reopening of ticket #18135. I agree the routing on AWS is slow and represents a large amount of connections. This is something that AWS needs to address. I will argue, however, that the AWS use case is a reason we need this to be an OPTION, not automatic. Genera

Re: Will be % string formatting be preferred in the future, or will string.format() be moving in?

Le lundi 18 février 2013 14:33:27 UTC+1, VernonCole a écrit : > > Dear Gurus: > I am a regular lurker on this list, and I have accepted the invitation > to use 1.5rc1 to help test it. My group is putting together a small (but > very important, we think) application which will use some features

Re: Database pooling vs. persistent connections

On 02/18/2013 06:47 AM, Jacob Kaplan-Moss wrote: > On Mon, Feb 18, 2013 at 7:41 AM, Aymeric Augustin > wrote: >> The goal of my proposal is to save the cost (in response time) of >> establishing >> the database connection, in vanilla Django, without compromising reliability. >> I'm trying to help

Re: select_for_update running on db_for_read

The correct patch would be: (Set _for_write on the cloned object rather than the original...) --- a/django/db/models/query.py +++ b/django/db/models/query.py @@ -664,6 +664,7 @@ class QuerySet(object): # Default to false for nowait nowait = kwargs.pop('nowait', False) ob

select_for_update running on db_for_read

Hi, I wanted to raise a but around this, but I thought it might be a better idea to ask first on the developer's group. If I'm running a select_for_update statement in a multidb environment that uses a read-only slave database, I get the following traceback: Traceback: File "/home/kux/workspac

Re: Database pooling vs. persistent connections

Also, https://github.com/niwibe/djorm-ext-pool is based initially on postgresspool but works with sqlite and mysql. The only difference is that uses monky patching instead a separate backend. We also use it in production on a project a while ago and has not given us any problems. Andrey 2013/2/

Re: Database pooling vs. persistent connections

On Mon, Feb 18, 2013 at 7:41 AM, Aymeric Augustin wrote: > The goal of my proposal is to save the cost (in response time) of establishing > the database connection, in vanilla Django, without compromising reliability. > I'm trying to help people who aren't even aware of the problem :) > > The impl

Will be % string formatting be preferred in the future, or will string.format() be moving in?

Dear Gurus: I am a regular lurker on this list, and I have accepted the invitation to use 1.5rc1 to help test it. My group is putting together a small (but very important, we think) application which will use some features of 1.5 and geodjango. I have also been reading the corresponding 1.5

Re: Database pooling vs. persistent connections

Le 17 févr. 2013 à 19:31, Anssi Kääriäinen a écrit : > I am not yet convinced that poolers implemented inside Django core are > necessary. In case I wasn't clear enough — I agree that Django core shouldn't provide connection pooling, because it'll be simplistic and hamper innovation outside of D

Re: Database pooling vs. persistent connections

+1 to django-postgrespool it works well for me. On Sunday, 17 February 2013 22:17:09 UTC, Carl Meyer wrote: > > On 02/17/2013 11:31 AM, Anssi Kääriäinen wrote: > > It seems SQLAlchemy has a mature pooling implementation. So, yet > > another approach is to see if SQLAlchemy's pooling implementati