Karl Putland wrote: > Geoffrey Talvola wrote: > > >Karl Putland wrote: > > > >>The one thing that I never figured out was how to use DBPool > >>in a fasion > >>that actually allowed the pool to exits once and keep the pool of > >>connections. > >>This was my motication to write my own pooling mechanism. > >>I see now that you store is as an instance variable somewhere in a > >>module that gets > >>used in the application. This was not obvious. It would be more > >>obvious if the > >>DBPool used it's own class variables or module variables to > store the > >>pool eg. > >>ConnectionPool stores the pool in a class variable with locks > >>around the > >>pool > >>creation. All instances of ConnectionPool in my case share > the same > >>physical > >>pool of connections. > >> > > > >Doesn't that limit you to a single ConnectionPool? What if you want > >multiple pools for different databases? > > > >Also, my intuition tells me that if I have 3 different instances of > >ConnectionPool, then they are really 3 different pools. I > wouldn't expect > >them to share the pool. > > > >I personally think that shared global resources like a > connection pool are > >best modeled in Python using module-level variables. I > agree that DbPool's > >documentation could be beefed up, but I think the idea is right. > > > >- Geoff > > > > Yes, but that's all I needed. > It would be trivial to change ConnectionPool to store the pool in an > instance variable. > It would then exibit the same behavior as DBPool. > > Just so I understand it, where do you initialize the pool? > In a module that gets imported? eg. > > #myutils.py > someConnectionPool = ConnectionPool(blah) > > > Then from other places, > > #SomeServlet.py > from myutils import someConnectionPool > def getData: > conn = someConnectionPool.get() > cur = conn.cursor() > result = cur.execute(someSQL) > cur.close() > conn.commit() > someConnectionPool.put(conn) > return result
Yes, that's the idea. > Would the construction of the pool in myutils.py need to be thread > protected? No, because Python guarantees (with some internal locking) that a module only gets imported once, even if there are multiple threads importing it at the same time. That's one of the reasons why it's a good idea to use module-level variables to store globals like this -- you get thread-safe initialization "for free". If you would rather have the pool be already constructed when the appserver starts up, you can put "import myutils" into the __init__.py file in your context directory. It will then get imported when the appserver starts up, before any requests come in. (It might help make the first request respond a bit faster, that's all.) - Geoff _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
