- All Implemented Interfaces:
- com.mchange.v2.c3p0.ConnectionTester, com.mchange.v2.c3p0.FullQueryConnectionTester, com.mchange.v2.c3p0.QueryConnectionTester, com.mchange.v2.c3p0.UnifiedConnectionTester, Serializable
public class MidPointConnectionTester
extends com.mchange.v2.c3p0.impl.DefaultConnectionTester
When getting serialization-related SQLException (as when getting any exception), c3p0 checks the connection
whether it is valid. However, in case of PostgreSQL, ANY 'select' command used for testing
(including 'select 1') fails in this situation with a message "current transaction is aborted,
commands ignored until end of transaction block". So the connection is released, and new one is
created, which leads to performance problems.
So it is probably best to roll the transaction back before checking the connection validity. To be safe,
we currently do this only for PostgreSQL; other databases (H2, MySQL) do not seem to have problems of this kind:
- MySQL does not even notice any serialization issues (why??? that's a bit suspicious)
- H2 checks the connection, but it can do that without problems within current transaction.
- Author:
- mederly
- See Also:
- Serialized Form