Christoph Zwerschke said: > I havent checked out DbConnectionPool yet. Which status has it? > Warren, are you still working on it? Are you/somebody else interested > in improving/testing this module and getting it into Webware, e.g. > MiscUtils? If yes, Id like to contribute if I can. >
I haven't done any work on it for quite a while, and the last work I did never made it into the sandbox. IIRC, I did a significant refactor of the code to extract the basic pooling logic into a super-class so that I could use it to build pools of other things besides database connections. While I was at it, I extracted the core expiration logic from the expiration thread so that it could be called by the "check in" code. This made it possible to cleanly make "aggressive" expiration non-optional with a minimal performance penalty. I also implemented usageCount expiration. The net effect of the expiration changes was to change the interface of startExpiration(), replacing the "aggressiveExpiration" boolean with an argument to specify the usageCount for usage based expiration. These changes have NOT been used in a production environment, and I haven't had time to develop a proper testing suite. I'll try to get the latest changes into the sandbox. I would welcome any help that you or anyone else could give in testing and further development. I would like to see DbConnectionPool included in WebKit, at least as an alternative to DBPool. > For the time being I have only tested DBPool.py. Here are my > questions/suggestions: > > * The module docstring talks about DB API. I think this should > be specified to DB API 2, since DB API version 1 has no > threadsafety attribute and thus will not work with DBPool. > > * There is an irritating comment that says: > > # These functions are used with DB modules > # that have connection level threadsafety, like PostgreSQL: > def _unthreadsafe_addConnection(self, con): > ... > > - Shouldnt it rather say ... that *DO NOT* have connection level > threadsafety...? (threadsafety 0 = not threadsafe, > 1 = module level, 2 = connection level, 3 = cursor level) > - PostgreSQL is not a DB module, but a DBMS, so shouldnt it say > like PyGreSQL or something (another PostGreSQL interface, > psycopg, has threadsafety=2)? > > * Wouldnt it be good to have minConnections and startConnections > in addition to maxConnections? This would be analogous to the > parameters in AppServer.config. > > * If a database connection crashes or gets disconnected, it will > never be restarted. Wouldnt it be good to let the getConnection > method check whether the connection is still usable and reopen > or restart it in case it is not? > > * My last important question: Maybe I understand something wrong, > but if I use DBPool for WebKit servlets, i.e. with the > ThreadedAppServer, wouldnt it be much more reasonable to > automatically bind the connections 1:1 to the servlet threads > created by the AppServer, instead of making an independent > database connection pool? So each thread would have its own > private database connection, servlets could never block each > other, there would be no threadsafety issues at all, > and you wouldnt need to configure any pool size, > but there would be always just as many connections as stated > in the AppServer.config. As far as I see it, this would have > only advantages. Do I overlook anything? > Could this be implemented with Webware/WebKit out of the box? > If not, shouldnt such a feature be added? > I share many of these concerns with DBPool. The one about "bad" connections being left in the pool is the one in particular that drove me to write DbConnectionPool, as I felt this issue was at least partly to blame for the "hung thread" issues that several were having. As far as the need to have a connection pool at all, you are right. There is probably a way for WebKit to handle this issue internally and therefore sidestep some of the thread safety issues. Some of my thoughts on this are: 1. Because of the way WebKit handles servlets and threads (a given instance of a servlet may be called by multiple threads during its lifetime, though only one at any given time), a connection stored as a servlet instance variable could still be called by more than one thread, dictating some thread safety within the database interface code. To mitigate this, the connection could be stored with the thread somehow. However, I don't think even this will protect extension code that is not at least minimally thread safe. 2. The problem of having a stored reference to a "bad" connection still exists, so some mechanism for dealing with these would still need to be implemented. In DbConnectionPool, I couldn't think of any good way of finding out if a connection was "bad", so I chose to implement the "expiration" concept as somewhat of a workaround. Although it doesn't directly address a "bad" connection, it does address one of the most common reasons why connections become unusable. 3. It would be preferable for the internal implementation to be able to manage other thread-specific resources in addition to database connections. In the past, Ian Bicking had expressed some interest in modifications to DbConnectionPool that would address thread safety issues in extension modules. He is probably much more familiar with what those issues are than I am. Also, Ian's latest work on Paste might dovetail with this, as it is an issue that is somewhat framework neutral. Ian, if you are reading this, would you care to chime in? -- Warren Smith [EMAIL PROTECTED] ------------------------------------------------------- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77&alloc_id492&op=click _______________________________________________ Webware-devel mailing list Webware-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/webware-devel
