New pooling (Long) [Was RE: Updates to the driver] - Mailing list pgsql-jdbc
From | Ned Wolpert |
---|---|
Subject | New pooling (Long) [Was RE: Updates to the driver] |
Date | |
Msg-id | XFMail.20011101090636.ned.wolpert@knowledgenet.com Whole thread Raw |
In response to | Re: Updates to the driver ("Dave Cramer" <Dave@micro-automation.net>) |
Responses |
Default configuration file
(Ned Wolpert <wolpert@yahoo.com>)
|
List | pgsql-jdbc |
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Folks- Last night I threw together a quick example of some ideas I have in the pooling mgmt for PostgreSQL's JDBC driver. The code can also found at: http://members.home.net/wolpert5/code/ First, I have some comments on the code I included, then I have questions for people. Comments: 1) Code shown here is not done. I've based it off of the PostgresqlDataSource code base. 2) Things not done include finishing JNDI naming stuff, thread for connection cleanup, using PSQLException, code cleanup, testing. (:-) In fact, don't run this example, just examine the way it works 3) I'm using logWriter for log writing. 4) Pooling technique include a) min number of connections b) max number of connections, c) Min number of 'available' connections, d) removing connections after SQLExceptions occured, e) cleanup 'unclosed' connections 5) The PostgresqlConnetionPoolDataSource is not serializable in my code. Should it be? (I figure not, since the pool is lost during serialization) 6) The technique for property-file usage is that it reads the default list first, which in the final jar, is org/postgresql/psqlProps.properties Then, it checks (in the classpath) for user properties at /psqlProps.properties, which overrides the default properties. Finally, the user of this class can set individual properties programmatically as well. Questions: 1) Is the log4j integration going to make use of the logWriter? Should we use both? 2) The PostgresqlConnetionPoolDataSource is not serializable in my code. Should it be? (I figure not, since the pool is lost during serialization) 3) In a JNDI layer, it 'almost' makes sense for a the connection pool to ma 4) The property technique, where defaults are read that exist in the jar file, user can have their own property file, and users can set properties programmatically seems good to me. What objections do people have? 5) Currently, if the username and/or password changes, I reset the entire pool. Is this bad? Should the ConnectionPoolDataSource contain multiple pools, each pool for each user/password combo? (With the ability flush a pool that is unused.) I figure I like my current implmentation, but I'm open to discussion 6) What package should the PostgresqlConnectionPoolDataSource be in? I figure the other items are definatly in the jdbc2 grouping. 7) Assuming this properties technique I have makes sense, should I move property retrieval into a more universally usable class in the utils directory? Or will no one else use it? 8) Any other comments other than code style. :-) (And yes, it does need some refactoring too.) Code included at these following links: http://members.home.net/wolpert5/code/PostgresqlConnectionPoolDataSource.java http://members.home.net/wolpert5/code/PostgresqlPooledConnection.java (I decided not to include them in this message. If people want me to send them to the list, I will) Remeber that the code is not completed, or in a usable state. Really, this is an example of my direction I'm working on, sorta an RFC, really. Thanks! Virtually, Ned Wolpert <ned.wolpert@knowledgenet.com> D08C2F45: 28E7 56CB 58AC C622 5A51 3C42 8B2B 2739 D08C 2F45 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE74XMMiysnOdCML0URAi9AAJ0UeXxmFX7EWhOJ4pS4obbyTXw4LACffyZ/ SXt1qHAliIll10rZC715Us8= =Ww+e -----END PGP SIGNATURE-----
pgsql-jdbc by date: