JP wrote: > James Bennett wrote: >> On 8/22/06, Karl Guertin <[EMAIL PROTECTED]> wrote: >>> SA provides: >>> * connection pooling - since you asked about it, I'll quote from the SA >>> docs: >> This is why I said "what comes to mind when I think 'database >> connection pooling' isn't something I think belongs in Django." >> >> Maintaining in-process connection pools in the framework doesn't, in >> my experience, provide enough benefit to justify the hassle. I'd >> rather talk to something like pg_pool which maintains an external >> connection pool. > > I think the problem here is competing definitions of the term > 'connection pool'. You're using 'connection pool' to mean a connection > that may be transparently directed to one of N databases (say where > records 1-1000000 are on database machine A and 1000001-200000 are on > database machine B, or you're writing to A and reading from A and B), I > think. And I think that Karl and Christopher are using 'connection > pool' to mean a collection of N persistent connections to the SAME > database, where threads in a web app can check out and use connections > from the pool, so that each thread need not make and hold its own > connection. > > So I agree, django's ORM doesn't need pools (definition 1), but it does > need pools (definition 2) to help it scale better in some environments > and to reduce request startup time. >
hmmm..so am i correct when i say, that in a non-multithreaded web-app definition-2-pools are not needed/ do not help? gabor --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
