[MDEV-13233] Idle transaction timeouts kills connections rather than transactions Created: 2017-07-02  Updated: 2017-07-06  Resolved: 2017-07-06

Status: Closed
Project: MariaDB Server
Component/s: Server
Affects Version/s: 10.3
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Elena Stepanova Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-11418 AliSQL: [Feature] Issue#1 KILL IDLE T... Closed

 Description   

Note: Possibly it's just a documentation issue; if it is so, please switch the category.

If idle_transaction_timeout or its siblings are set, and the timeout is exceeded, not only the open transaction closes, but the entire session (connection) gets dropped.

MDEV-11418 (KILL IDLE TRANSACTIONS) only speaks about killing transactions; documentation is even less verbose in this regard, but it also only mentions transactions; finally, the tests in pull request, although they enable reconnect and thus apparently expect the connection to be lost, do not show it specifically.

Killing the entire session seems to be excessive for the declared goal, but if it has to be so, please document it properly. The difference in semantics is similar to KILL <id> vs KILL QUERY <id>, and it is essential for setting up proper workflow and tuning applications which might be affected by the timeouts.

MTR test case

 
--connect (con1,localhost,root,,)
 
set idle_transaction_timeout= 2;
 
--enable_reconnect
 
BEGIN;
 
SELECT CONNECTION_ID();
 
--sleep 3
 
--error 2006,2013
 
SELECT "Dead";
 
SELECT CONNECTION_ID();
 
--disconnect con1

Actual result

 
connect  con1,localhost,root,,;
 
set idle_transaction_timeout= 2;
 
BEGIN;
 
SELECT CONNECTION_ID();
 
CONNECTION_ID()
 
5
 
SELECT "Dead";
 
Got one of the listed errors
 
SELECT CONNECTION_ID();
 
CONNECTION_ID()
 
6
 
disconnect con1;



 Comments   
Comment by Sergey Vojtovich [ 2017-07-06 ]

According to plinux comment this feature is mostly used to cope with broken application that forget to commit/rollback. For such applications it doesn't make too much difference how their transaction was interrupted.

I believe decent applications have to handle "lost connection" independently of this feature.

But I agree it is excessive. The reason for this approach was simplicity: interrupting transaction without killing connection is a lot more complex. It is fairly simple to interrupt running command: just set a flag and wake thread if it is sleeping. In this case there's no command running. It is also unclear how error should be reported: subsequent statement returns error? Or all subsequent statements fail until explicit rollback is issued?

I don't think we should bother implementing fair transaction termination at least until there's reasonable need for this.

greenman, could you adjust manual so that it reflects that connection is terminated when transaction timeouts?

Comment by Ian Gilfillan [ 2017-07-06 ]

Docs now specify that the connection is killed

Generated at Thu Feb 08 08:03:57 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.