Dear Andrea,
I think the better way to handle this is by closing the connection in a
finally block.
Kind regards,
Joachim
On 05/16/2011 11:17 AM, Andrea Aime wrote:
> Hi,
> today I was looking into the JDBC data store due to some connection
> leaks reported in a very busy production server on too small for the
> job hardware and noticed patterns like this in connection handling:
>
> try {
> // this allows PostGIS to page the results and respect the
> fetch size
> if(getState().getTransaction() == Transaction.AUTO_COMMIT) {
> cx.setAutoCommit(false);
> }
>
> SQLDialect dialect = getDataStore().getSQLDialect();
> if ( dialect instanceof PreparedStatementSQLDialect ) {
> PreparedStatement ps =
> getDataStore().selectSQLPS(querySchema, preQuery, cx);
> reader = new JDBCFeatureReader( ps, cx, this,
> querySchema, query.getHints() );
> } else {
> //build up a statement for the content
> String sql = getDataStore().selectSQL(querySchema, preQuery);
> getDataStore().getLogger().fine(sql);
>
> reader = new JDBCFeatureReader( sql, cx, this,
> querySchema, query.getHints() );
> }
> } catch (Exception e) {
> // close the connection
> getDataStore().closeSafe(cx);
> // safely rethrow
> throw (IOException) new IOException().initCause(e);
> }
>
> Uh, in case of OOM (or any other kind of Error) inside the try/catch
> block the connection would
> not be closed properly.
> I want to change those bits to catch Throwable instead.
>
> Opinions?
>
> Cheers
> Andrea
>
--
Joachim Van der Auwera
Geosparc, supporting the Geomajas GIS community
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel