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

[spring-projects-issues]

Kazuki Shimizu opened SPR-14038 and commented

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

e.x.)

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

    @Autowired
    private JdbcTemplate jdbcTemplate;

    public void execute1() throws InterruptedException {
        TimeUnit.SECONDS.sleep(3);
         jdbcTemplate.execute("...");  // Detect transaction timeout !! -> Rollback !!
        TimeUnit.SECONDS.sleep(0);
    }

    public void execute2() throws InterruptedException {
        TimeUnit.SECONDS.sleep(1);
         jdbcTemplate.execute("..."); // Commit by DataSourceTransactionManager ... 
        TimeUnit.SECONDS.sleep(2);
    }

}

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-attic/spring-framework-issues@3c2a425, spring-attic/spring-framework-issues@2b20a1a

[spring-projects-issues]

Kazuki Shimizu commented

I've added repro project.
spring-attic/spring-framework-issues#123

[spring-projects-issues]

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.

Juergen

[spring-projects-issues]

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:

e.g.)

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) ?

Thanks.

[spring-projects-issues]

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