geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Testing SQL connection before return in outbound connection pool using spring
Date Mon, 14 Sep 2009 16:29:14 GMT

On Sep 14, 2009, at 1:54 AM, Rafal Rusin wrote:

> Hello,
> I tried to configure a testing SQL connection factory in ServiceMix,
> but I haven't found any signs of it's existence. ServiceMix is based
> on Geronimo, so I thought it's a good place to ask.
> I need it, because after database restart Geronimo's
> org
> .apache.geronimo.connector.outbound.connectionmanagerconfig.SinglePool
> returns closed connection each time getConnection is executed.
> Is there a way to configure in Spring something like
> TestablePoolFactoryBean instead of SinglePool, with testSql attribute,
> which would inject SQLTestingInterceptor for testing sql connection
> before return? This would solve my problem.
> BTW. Most application servers have a possibility to configure test sql
> in connection pool, so there must be something in Geronimo too.

I don't remember too clearly but I don't think I implemented support  
for this.  There may be an optional j2ca 1.5 feature to support this  
style of use, and it wouldn't be hard to implement, and contributions  
are always welcome.

My thinking on the subject was that connections rarely break, but can  
break at any time -- for instance in the middle of a transaction.   
Therefore your app has to be able to deal with this kind of failure  
anyway.  So to me it seems that the "test before letting out of the  
pool" style is going to slow down your app for every normal request  
while not relaxing the error recovery features you will need.  I also  
thought that since the db restart is presumably done under an admins'  
control, the admin could also flush the db pool.  I don't recall if we  
have a command to do this, but it seems like a less invasive technique  
than testing each connection for each use.

The important feature to me is that once you discover that a managed  
connection is broken, it be removed from the pool.  There's a  
mechanism using the ConnectionEventListener to deal with this, but it  
relies on the tranql wrapper being able to decide accurately whether  
an exception means the connection is no longer usable.  The vendor  
specific wrappers generally use the similar XADataSource feature to  
determine this, but the generic wrapper has no way to decide, so by  
default it assumes all exceptions are fatal errors.

david jencks

> Regards,
> -- 
> RafaƂ Rusin

View raw message