Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cannot detect transaction timeout after query execution on DataSourceTransactionManager [SPR-14038] #18610

spring-projects-issues opened this issue Mar 10, 2016 · 4 comments


Copy link

@spring-projects-issues spring-projects-issues commented Mar 10, 2016

Kazuki Shimizu opened SPR-14038 and commented

Currently, there are cases where the transaction in excess of the timeout period is committed.


@Transactional(timeout = 2) // Timeout is 2 sec
public class TransactionalService {

    private JdbcTemplate jdbcTemplate;

    public void execute1() throws InterruptedException {
         jdbcTemplate.execute("...");  // Detect transaction timeout !! -> Rollback !!

    public void execute2() throws InterruptedException {
         jdbcTemplate.execute("..."); // Commit by DataSourceTransactionManager ... 


This behavior is same with JpaTransactionManager and JmsTransactionManager.
If JtaTransactionManager is used, we can detect a transaction timeout.

I hope to detect timeout at committing. What do you think ?

Affects: 4.2.5

Referenced from: commits spring-projects/spring-framework-issues@3c2a425, spring-projects/spring-framework-issues@2b20a1a

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 10, 2016

Kazuki Shimizu commented

I've added repro project.

Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 10, 2016

Juergen Hoeller commented

This is unfortunately a fundamental limitation of timeout handling against native resources: They all just support timeout hints but no timeout enforcement. As a consequence, a Spring-specified timeout is also just a hint: It may lead to an enforced timeout depending on the transaction manager (like in the JTA case where a parallel cleanup thread cancels timed-out transactions) but usually just suggests a timeout to the underlying resource. This is similar to a Spring-specified read-only flag which is also just an optimization hint, not a hard enforcement.

We could theoretically cancel a transaction at commit time if we determine that it took too long. However, that seems wasteful: The operations did succeed by then, and with a native transaction manager, the subsequent commit signal is usually a quick step to take. Enforcing a timeout at that late point, for a transaction which essentially has been successful, seems counter-intuitive. After all, timeouts are primarily there to avoid hanging when an operation runs into a lock, not for a hard cancel attempt when an operation happened to take slightly longer than expected.


Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Mar 11, 2016

Kazuki Shimizu commented

Juergen Hoeller, thanks for answer !!!
I understand your opinion and agree it.

However, in my application, it want to ensure rollback a transaction, if read-timeout was detected at Client application.

My team was consider a following solution:


Client <-------------- HTTP ------------> My REST API <----- JDBC / HTTP -----> DB / Other REST API 
       (read-timeout=tx-timeout + M sec)                 (tx-timeout=N sec)                

If can ensure to rollback transaction when transaction timeout was occurred, we thought this issue can be resolved by timeout desgin except for the rare case.
However, the DataSourceTransactionManager has not been ensured it.

Have best practice to implements this specification on spring application(actually, spring boot application) ?


Copy link
Collaborator Author

@spring-projects-issues spring-projects-issues commented Jan 12, 2019

Bulk closing outdated, unresolved issues. Please, reopen if still relevant.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.