I was quite surprised to find out there isn't any connection pooling built in to Django or (at least some of) its DB beack-ends when I've first researched about it. Other people have correctly pointed out that this is a latency issue that affects both low and high traffic sites. Since there is already an abstraction layer over the various db backends, I find it quite logical to implement the connection pooling on top of it, instead of relaying on an external tool. I believe an optional simple pool with min/max connections settings would do the trick for most of the people without any side effects, and the line before the slippery slope can be drawn there. It might be a good idea to leave an extension point for manipulating a connection object taken out of the pool, in order to reset its state.
When I've researched for connection pooling solutions I've found various hacks for cloning and modifying the backends to use sqlalchemy or psycopg connection pools. This seems like a pretty crude solution, which perhaps highlights the need for a better solution (or at least a better extension point) within the framework. I have found little information regarding any "external connection- pooling utilities", except the mention of pgpool in Django book. I believe there might be a few situations when installing such an external utility is problematic (shared hosting), and more cases where developers would prefer to simply switch on a setting. Nonetheless, I would be happy to be educated about external pooling utilities which were proven to work well with Django and various DB backends (namely PostgresSql and MySql). So to sum up: I vote up connection pooling. Where do I sign up? > > So we see that this isn't a pointless slippery-slope argument: > connection pooling is an inevitable outcome of your approach, just one > you've yet to accept. > > But it gets worse: you'd want this mechanism to be independent of the > web server processes/threads in which the connections are used, > because you don't want to have to have one connectionpoolper server > process (since that just reintroduces the problem of latency every > time you spin one up and increases overhead and code complexity) and > you don't want the connectionpoolto be killed if the process which > hosted it gets recycled by the server. Which points to... an external > connection-pooling utility. > > Such utilities already exist and are usable right now. They don't > belong in Django (for many reasons, "don't reinvent the wheel" being > only one of them). > > -- > "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@googlegroups.com To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-users?hl=en -~----------~----~----~----~------~----~------~--~---
