Per-Statement QueryTimeout for JdbcTemplate

[MahatmaFatalError]

Context:
As described here (#7444) it is possible to set a general query timeout for JdbcTemplate. However, having in mind that JdbcTemplate typically is a singleton bean, this is not sufficient when it comes to thread-per-request handling. Setting the queryTimeout state once would affect every subsequent query and interfere with parallel threads that use the JdbcTemplate bean.
The use case is to easily set statement timeout individually and dynamically (e.g. because of expected query runtime that is affected by different statement params).

Proposal for new feature:
Overloading once more the execute(), query(), queryForX() and update() methods by adding a timeout parameter that then gets passed though the stack (i.a.applyStatementSettings()) to finally call setQueryTimeout on the Statement.

Further References:
https://jira.spring.io/browse/DATAJDBC-638

[snicoll]

Thanks for the suggestion and sorry it took so long to review it.

Overloading once more the execute(), query(), queryForX() and update() methods by adding a timeout parameter that then gets passed though the stack (i.a.applyStatementSettings()) to finally call setQueryTimeout on the Statement.

We need to draw a line in how far we go with overloading. Our template-based approach has always favored centralized configuratio over per-request configuration to limit the number of arguments. The method you reference is configuring three settings. Doing it for the query timeout means that someone else could legitimately ask us to support the other two.

You can create a JdbcTemplate from an existing template by getting its dataSource and configure a different timeout.

[MahatmaFatalError]

OK, I understand. However, for the sake of convenience, would it be possible to simplify the configuration? E.g. by introducing a builder or static creator method for JdbcTemplate?

[snicoll]

Nothing prevents you from doing that in your own code and the API can be optimized for your use cases. Introducing a builder will have the same drawback of having to expose too many or too few options depending on the use cases. See JdbcTemplate (or any template really) as a building block.