Folks-
I'm re-examing the PostgresDataSource class, and it seems that I missed
a few things. I need someone to verify what it is I'm looking at. This is
based on my pooled stuff I submitted eariler, and the current conversation
that has been going on about my submittal.
Basically, it seems that the XADataSourceImpl is a working pooling
manager. It is an abstract class, only extended by PostgresqlDataSource.
The XADataSourceImpl provides the access to the pool from their method
newConnection() and releaseConnection(), neither of which are called
elsewhere.
It looks like the code was expecting the org.postgresql.jdbc2.Connection
object to 'release' it if it was called by the datasource, when the
connection was closed, but the Connection class was never modified. In
short, the pool is almost there already, just not complete. The class
PostgresqlDataSource _can_ pool, it just doesn't. Does this look like
a proper analysis to others?
I can do one of two things at this point, and I would like people's
opinion as to what I should do. One, I can continue working on my pool
manager, which will extend XADataSourceImpl and will still have to wrap
the connection classes to notify my pooling manager of changes that
occurs. or Two, create a set of patches that will impact the jdbc2
package and PostgresDataSource class to finish what was started.
What do you think folks? I'm starting to lean to option two, but would
like to hear other people's opinions. If we pick two, that means
that my pooling manager is _part_ of the PostgresDataSource, not a
seperate class. Could some of the CVS committers comment on this?
(Also, I'll be having patches for basically all the classes in the jdbc2
and xa package.)
=====
Virtually, | "Must you shout too?"
Ned Wolpert | -Dante
wolpert@yahoo.com |
_________________/ "Who watches the watchmen?"
4e75 -Juvenal, 120 AD
-- Place your commercial here -- fnord
__________________________________________________
Do You Yahoo!?
Send your FREE holiday greetings online!
http://greetings.yahoo.com