On Feb 18, 1:01 am, Florian Apolloner wrote:
> Yes, ABORT + DISCARD should do it for postgres (or ABORT; RESET ALL; SET
> SESSION AUTHORIZATION DEFAULT if pg < 8.2)
Inspired by this thread, I did some work for 3rd party database
connection pooling. What I have is at https://github.com
Yes, ABORT + DISCARD should do it for postgres (or ABORT; RESET ALL; SET
SESSION AUTHORIZATION DEFAULT if pg < 8.2)
Cheers,
Florian
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.g
Hi,
On Friday, February 17, 2012 11:08:40 PM UTC+1, Cal Leeming [Simplicity
Media Ltd] wrote:
>
> Could you elaborate on this a bit more? And would this affect MySQL?
Well there isn't much more to it than a "ABORT; DISCARD ALL" at the end of
the session to discard changes and clean (abort) and
On Fri, Feb 17, 2012 at 4:58 PM, Florian Apolloner
wrote:
> This approach has quite a few issues on it's own, eg for postgres if the
> transaction is broken all following requests will raise a 500. You have to
> at least reset the connection state to something useable again.
what about not closin
On Fri, Feb 17, 2012 at 9:58 PM, Florian Apolloner wrote:
>
>
> On Friday, February 17, 2012 10:11:57 PM UTC+1, Cal Leeming [Simplicity
> Media Ltd] wrote:
>>
>> # Apparently this will stop many connections to MySQL
>> from django.core import signals
>> from django.db import close_connection
>> si
On Friday, February 17, 2012 10:11:57 PM UTC+1, Cal Leeming [Simplicity
Media Ltd] wrote:
>
> # Apparently this will stop many connections to MySQL
> from django.core import signals
> from django.db import close_connection
> signals.request_finished.disconnect(close_connection)
>
This approach
close_connection
signals.request_finished.disconnect(close_connection)
Although it's not connection pooling, it does stop the original problem of
lots of connections to the db.
I'd love to see this as a 'settings.py' option, does anyone else think this
would be a good idea?? Someth
Hi Russ,
Thanks very much for the reply. I guess ultimately my question was "do any
of the connection pooling solutions have an impact on the
stability/performance of Django, or more importantly, cause any problems
with the ORM?"
I had very little luck in finding write ups by anyone on
Hi Cal,
I'm not exactly sure what it is you're looking for.
The position of the core team has been fairly clear -- there are third
party connection pooling tools that handle connection pooling very
well.
The recommendation of the core team is that you should use these tools.
The alte
'm still not clear on the MySQL
> connection pooling topic.
>
> To quote Russ: "the capability already exists in third party tools, and
> they're in a position to do a much better job at it than us because it's
> their sole focus" [3]
>
> Could a
Hi all,
After spending about 30 minutes looking through old tickets, long
discussion threads and various blogs, I'm still not clear on the MySQL
connection pooling topic.
To quote Russ: "the capability already exists in third party tools, and
they're in a position to do a much b
On Sun, 2008-11-16 at 11:57 -0800, jothan wrote:
> PsycoPg2 with a remote DB over a WAN is deadly slow. Since PsycoPg2
> supports connection pooling, I have decided to patch the Django DB
> adapter to use this. I could see this implemented as below (this is a
> very rough draft).
WAN is deadly slow. Since PsycoPg2
> supports connection pooling, I have decided to patch the Django DB
> adapter to use this. I could see this implemented as below (this is a
> very rough draft). For example, min and max connections should not be
> hardcoded.
>
> Let me know wha
PsycoPg2 with a remote DB over a WAN is deadly slow. Since PsycoPg2
supports connection pooling, I have decided to patch the Django DB
adapter to use this. I could see this implemented as below (this is a
very rough draft). For example, min and max connections should not be
hardcoded.
Let me
JP Farias wrote:
>Hmmm... Some question come to my mind now...
>
>1. Does django uses only one connection for the whole process?
>
>2. Does it open and close a connection once for every request?
>
>
The second is true.
>3. Can django handle many requests at once (multi-threaded or something
>e
Hmmm... Some question come to my mind now...
1. Does django uses only one connection for the whole process?
2. Does it open and close a connection once for every request?
3. Can django handle many requests at once (multi-threaded or something
else)?
--
JP
--~--~-~--~~---
On 4/1/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> Is there any mecanism of database connection pooling in django ?
Not at the moment, but some of the changes in the magic-removal branch
seem like they'd make this much easier to implement in the future.
--
"May the fo
Hi all,
Is there any mecanism of database connection pooling in django ?
--
Zeuxis
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, sen
18 matches
Mail list logo
