Stijn de Witt wrote:
The advantage of mastering the Commons Pool options is that this will
work with all database servers that OJB supports, not just MySQL.
Do you know if the autoReconnect=true option alone will fix it? I have
seen mention of autoReconnectForPools option? We are not planning on
migrating away from MySql anytime soon. As I understand it, I shouldn't
'play it save' and use autoReconnect=true in combination with the
Evictor thread solution?
The MySQL-specific autoReconnectForPools will not apply when using OJB
connection pooling, only if you use a MySQL JDBC-driver configured
connection pool. The Oracle JDBC-driver has a similar feature in recent
versions.
Bascially, what the JDBC-driver specific pooling feature does is saving
you in case the application does not provide pooling.
Since OJB provides connection pooling I would recommend _not_ to use MySQL
driver-controlled pooling to avoid getting a messy configuration.
(Random thought, not verified:
If you activate a MySQL connection pooling together with OJB dito, you
might end up allocating a whole MySQL connection pool for each Connection
that you check out from the OJB pool.)
The MySQL URL-paramater autoReconnect=true and Commons Pool
testOnBorrow=true will both solve your immediated problem and with
just a few msecs apart as to when it happens
(autoReconnect is like "testJustAfterBorrow").
Could you review these settings for the evictor thread solution? Do you
think these settings are ok?
validationQuery="select 1"
minEvictableIdleTimeMillis="60000"
timeBetweenEvictionRunsMillis="120000"
numTestsPerEvictionRun="10"
testWhileIdle="true"
testOnBorrow="false"
testOnReturn="false"
Could I combine these with autoReconnect="true"? Would that be useful?
Which of the two options would you use?
This looks like a good setup to me! Personally, I would recommend you
to set testOnBorrow="true" and leave the autoReconnect URL paramater
out of the equation.
I just like to keep all settings consistent and leave all validation
up to Commons Pool API, without relying on the JDBC-driver to do
additional checks. (But this is just a matter of "taste" and I would
think you can't measure any big performance issues between the two.
I would assume that the driver-internal method would have the chance
of a quicker validation mechanism than issuing a validation query
through JDBC but the big overhead should be TCP/IP socket creation
and network traffic anyway so it probably matters very little).
The benefit of doing what you do: combine an evictor thread with
testing on borrow makes the probability of Connections being broken
on borrow less (since the eviction runs will probably catch some
of those). This should ie raise the probability for faster response-
times on borrow (no need to discard object from pool and create new
Connection if this was done while idle).
I use "probability" just because you can't tell this deterministically
without making some sort of mathematical proof of the whole application
and all external factors. ;)
Regards,
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
