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.
thanks david jencks
Regards, -- Rafał Rusin http://www.touk.pl http://top.touk.pl http://www.mimuw.edu.pl/~rrusin
