New pooling (Long) [Was RE: Updates to the driver]

-----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(dot)wolpert(at)knowledgenet(dot)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-----