Jorgen Thelin wrote:
>
>
> Robert,
>
> The biggest problem is that you will then have a connection pool on top
> of a connection pool. As the "topmost" pool (Jonas in this case) will
> not actually close the underlying connection while it holds the
> connection in it's pool, it is very unlikely that there will be any
> interaction with the in the underlying pool that would give any benefits
> of the second pool.
> .... snip ....
>
> - Jorgen
>
>
Hi,
I agree with you that a second pool underneath is not a clean solution and
will not help in terms of performance. However, my current problem is fault
tolerance and I need a quick solution as problems related to stale database
connections have occured quite frequently in one of our projects. JDBCPool
is stable, proven code, that's been around for a while and I just thought
that the timeout capabilities that are already there could help us with our
problem without having to interfere with JOnAS code too much.
I've just finished implementing the following:
modify the container code so that it
- looks for an additional datasource param indicating that jdbcpool should
be used for this data source
- sets up the pool using additional parameters given in the data source
properties (timeouts, maxconnections, monitor interval etc.)
modify the connection manager so that it
- checks if a connection is closed when it is taken from the pool (takes
under 1 ms with oracle)
- if it finds a closed connection that's not associated with a transaction,
reopens it
the two modifications are just a few lines of code, it works, still allows
using standard jonas behaviour (you can choose for each datasource) and
helps me use a very conservative, fault-tolerant setting for my project
without any relevant performance penalty.
question: does the pooling code in JOnAS ever drop pool items? I did not see
that in the code. if it doesn't, then there is one more positive side effect
to the jdbcpool approach: by specifying the timeouts appropriately you get a
pool that automatically shrinks after load peaks that forced opening lots of
connections.
I'm not promoting this as the best solution that's here to stay but at the
moment it gives us what we need in terms of fault tolerance in our projects
until the pooling code has improved in that regard.
Robert
--
(-) Robert Kr�ger
(-) SIGNAL 7 Gesellschaft f�r Informationstechnologie mbH
(-) Br�der-Knau�-Str. 79 - 64285 Darmstadt,
(-) Tel: 06151 665401, Fax: 06151 665373
(-) [EMAIL PROTECTED], www.signal7.de
