@JUnitTemporaryDatabase tests do not use connection pooling
Description
When we use @JUnitTemporaryDatabase in unit tests, our temporary PostgreSQL database calls DataSourceFactory.setInstance(database) to set itself as the default javax.sql.DataSource. However, this means that there is no connection pooling using c3p0 during the unit tests. This is leading to socket exceptions during some database-intensive unit tests because hundreds of database connections are being opened and closed quickly enough to exhaust the available ephemeral client ports.
We need to change TemporaryDatabaseExecutionListener to wrap the datasource in a c3p0 pool.
This probably isn't an issue with atomikos since its javax.sql.DataSource is implemented using a pooled javax.sql.XADataSource resource.
Acceptance / Success Criteria
None
Lucidchart Diagrams
Activity
Show:
Seth Leger April 2, 2015 at 10:35 AM
I added c3p0 pooling to the unit tests. The reason this was probably not already in place is that our c3p0 does not shut down all database connections successfully on close() but I added a SQL call that will forcefully terminate connections before issuing the DROP DATABASE command.
When we use @JUnitTemporaryDatabase in unit tests, our temporary PostgreSQL database calls DataSourceFactory.setInstance(database) to set itself as the default javax.sql.DataSource. However, this means that there is no connection pooling using c3p0 during the unit tests. This is leading to socket exceptions during some database-intensive unit tests because hundreds of database connections are being opened and closed quickly enough to exhaust the available ephemeral client ports.
We need to change TemporaryDatabaseExecutionListener to wrap the datasource in a c3p0 pool.
This probably isn't an issue with atomikos since its javax.sql.DataSource is implemented using a pooled javax.sql.XADataSource resource.