commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roytman, Alex" <Roytm...@peacetech.com>
Subject DBCP: Jdbc2PoolDataSource needs attention
Date Fri, 01 Nov 2002 18:04:07 GMT
Dear apache-commons developers,

Jdbc2PoolDataSource is a very useful component however I believe it is not up to "release"
quality yet
While working with it I found some things I would like to improve or change. 
Please forgive me if I misunderstood certain things in Jdbc2PoolDataSource design as I could
only spend limited time testing, debugging and reading its source

1. mutable poolable keys are very dangerous and lead to errors. One subtle error which rendered
entire component useless in case of getConnection(username, password) was due to this error
http://issues.apache.org/bugzilla/show_bug.cgi?id=13235

2. new pool gets created for every different user getConnection(username, password). Also
due to pool design if user wants eviction each pool will span an eviction thread which can
easily bring any server to its knees. I think creating new pool for each user is related to
ability to configure each user separately. My believe it is really not an objective because
a) as much as possible in their projects people should use pools which are fully configured
and do not use getConnection(username, password) but getConnection() instead and b) if they
do need pool which caters for application where username/password is supplied by user for
each session rather then configured in application this pool should have no reason to configure
different users differently (as it has no prior knowledge of its users)
Also for this kind of pool it is important to be efficient as number of users can be very
high
and we should be extra careful to survive programming mistakes or malicious users in this
case

3. In current implementation once a pool for particular user/password got created and have
some idle connection a user with INVALID password but right user name can grab connections
from the pool (have not tested but it looks like it is the case)

4. failed connections get suck in active pool

5. Not sure why we need to keep a static map of all pools by datasource. J2EE environment
will call jndi environment getObjectInstance() only once to create a pool and then the environment
will keep the reference and will not call factory method on each object lookup but return
previously created instance

6. weak cache of UserPassKeys by PooledConnections. if PooledConnections re-implements 

7. XA interface?

As an exercise (and because I need it ASAP for my projects) I re-implemented Jdbc2PoolDataSource
(well I just wrote it from scratch yesterday). It is also based on commons-pool component
and I tried to take in the consideration some of the issues I mentioned above. It is an RND/alpha
level code and not all features are implemented but I am planning to finalize it shortly (actually
it depends on pool latest features invalidateObject() and doEvict()) as I need it for my production.
I expect to get it to beta quality in couple of weeks. I would be glad to contribute it to
apache if there is any interest. 

some features:

- getConnection(username, wrong-password) will not affect pools for the same user name and
valid password and will not be able to utilize them either 
- UserKey objects are immutable and cached in a map (HashMap right now but it could be apache's
LRUMap to make sure it does not grow indefinitely)
- Bad connections do not get stuck in active pool
- Connections are marked bad based on ConnectionEventListener.connectionErrorOccurred() and
get removed from a pool on next activate/passivate
- On getConnection() if any idle connection is bad it will be destroyed and another attempt
to get connection made transparently for user. It will be done till a good connection is obtained
but not more than idleNum+1 attempts to be made (tested with oracle)
- Use shared eviction thread across multiple pools. This has not been implemented yet. I am
planning to allow pool to have setTimer(Timer timer) or setTimerName(String jndiName) which
will subscribe pool to receive time events from  a timer. In j2ee environment timer should
be defined in context environment and looked up by jndi name. Timer could be custom developed
or preferable java.util.Timer (although as Rodney mentioned it requires jdk1.3)
- Optionally prohibit getConnection(username, password) allow getConnection() only (could
be important for XA vs. local transactions) not implemented yet

and more...


Thank you very much for your attention

Alex Roytman
Peace Technology, Inc.
roytmana@peacetech.com

--
To unsubscribe, e-mail:   <mailto:commons-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:commons-dev-help@jakarta.apache.org>


Mime
View raw message