Ronald Koster opened SPR-1972 and commented

JdbcTemplate should have 2 extra methods:

/**
* Like #setMaxRows(int) but now encapsulates java.sql.Statement#setQueryTimeout(int)
* instead of java.sql.Statement#setMaxRows(int).
* WARNING: Not all JDBC drivers support this feature!
  */
  public void setQueryTimeout(int seconds)

/**
* Invokes java.sql.Statement#cancel() on the statement in execution.
* Never throws an exception but does log a warning when Statement#cancel()
* throws an exception.
* WARNING: Not all JDBC drivers and DBMS systems support this feature!
  */
  public void cancelQuery()

This will allow for convenient constructions like this (within a JdbcDaoSupport instance):

JdbcTemplate template = getJdbcTemplate();
template.setMaxRows(501);
template.setQueryTimeout(30);
try {
return template.queryForList(sql, args);
} catch (RuntimeException rex) {
LOG.warn("Query has failed.", rex);
template.cancelQuery(); // Just in case.
throw rex;
}

NB.

  1. The cancelQuery method requires JdbcTemplate to keep a reference to the statement object in execution.
  2. When the JDBC driver does not support the query timeout mechanism, but does support Statement#cancel(), one can invoke cancelQuery from another thread (eg. using a timer task).
  3. When the encapsulating JdbcDaoSupport is a singleton in a multi-threaded environment, you will need to have a separate instance of JdbcTemplate per thread, or else the threads may cancel the wrong query. Then the JdbcDaoSupport should invoke:
JdbcTemplate template = new JdbcTemplate(getDataSource());

instead of:

JdbcTemplate template = getJdbcTemplate();

No further details from SPR-1972

Comment From: spring-projects-issues

Jon Osborn commented

Woudn't you setup your JDBC pooling to deal with this?

Comment From: spring-projects-issues

Rossen Stoyanchev commented

This issue has been resolved through a selective bulk update, as part of a larger effort to better manage unresolved issues. To qualify for the update, the issue was either created before Spring 3.0 or affects a version older than Spring 3.0 and is not a bug.

There is a good chance the request was made obsolete, or at least partly outdated, by changes in later versions of Spring including deprecations. It is also possible it didn't get enough traction or we didn't have enough time to address it. One way or another, we didn't get to it.

If you believe the issue, or some aspects of it, are still relevant and worth pursuing at present you may re-open this issue or create a new one with a more up-to-date description.

We thank you for your contributions and encourage you to become familiar with the current process of managing Spring Framework JIRA issues that has been in use for over a year.

Comment From: kortov

it was a long 2012, is there a chance to re-review it, because it seems quite needed. The question on SO got 9k views and no easy/beautiful solution