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:

Previous
From: "Mihai Gheorghiu"
Date:
Subject: Off-topic: Help wanted
Next
From: tony
Date:
Subject: Re: Staroffice, druid, dbvisualizer compatability