Jorgen Thelin wrote:
> Robert Krueger <[EMAIL PROTECTED]> writes
>
> <SNIP>
>
> >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)
>
> Can I ask how you do this?
>
> Is it just by calling connection.isClosed() or do you do something like
>
yup
> execute a simple SQL statement such as "SELECT 1;" to force a round-trip
> to the database?
>
> >From my understanding of the JDBC API, the former will not be of any
> practical use [one of the silliest methods in the whole Java core API,
> IMHO]
>
you're basically right that it is not of practical use for detecting if
something is wrong with the connection. in this case what it does reliably is
check if the connection has been closed by jdbcpool due to a timeout. this is
enough to implement the following (really ugly, I admit) strategy:
- specify a very low timeout value for the use of connections
- reopen them if they have been closed due to timeout
again, please out this in the right perspective. the motivation for this was to
get rid of those (very frequent) errors that were caused by a dropped
dbconnection ("morning bug"). I'm not promoting this for general purpose use.
It helped me and I'm only posting this because there might be people with the
exact same problem out there.
I'll attach a little readme for those who are interested
>
usage of the jdbcpool connection management:
---------------------------------------------
disclaimer:
I think this code works but have not thoroughly tested it and there is no
guarantee whatsoever that it will not break something. this is merely something
that buys people time who need a little more control over connection management
in JOnAS, especially to avoid errors when the database connection goes down and
the server is not restarted.
the code has been modified in a way that it doesn't affect the normal behaviour
of JOnAS. the modified code only comes into effect when you specify certain
additional datasource properties.
here's how it works:
jdbcpool code behaves just like a jdbc driver, so it can be plugged underneath
JOnAS connection pool management. consequently it will not affect performance
as the real "pooling" is done by JOnAS. what it does do, is limit the maximum
number of concurrent connections for a given datasource and give you the
possibility to specify timeouts for certain things. to set up the pools a minor
modification has been to the container code that still behaves normal except
that when you specify the property.
datasource.useJdbcPool yes
it will use jdbcpool for this datasource and set up the pool with the given
properties, i.e.
datasource.monitorInterval 10
max number of connections that can
be opened by this datasource
datasource.maxConnections 10
seconds a connection can be idle
before it is closed
datasource.maxIdle 360
seconds a connection can be checked
out (in this case it will look to
jdbcpool as if the connection is never
returned because JOnAS pooling is
on top, so this value should not be
too low)
datasource.maxCheckout 3600
number of times a connection can
be re-used (does not make too much
sense here, as the connection is
usually just checked out once by
JOnAS connection pooling)
datasource.maxUsage 100
force checking for closed connections when taking from the pool
you really should to set this to true if you use
jdbcpool because otherwise timed out connections
will cause errors
datasource.paranoid true
with the paranoid setting, the JOnAS ConnectionManager will check each
connection that is retrieved from the pool if it is closed (e.g. due to a
jdbcpool idle timeout) and reopen it if it's not in a transaction.
the modification of XADataSourceImpl.java was necessary to allow null values
for username and password as that is needed for jdbcpool to work.
I have also made a slight modification in the semantics of jdbcpool's
definition of "last accessed" so you'll need the patched version. I've asked
the jdbcpool people to include this change in the main branch but have not
received feedback yet.
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
