Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.3(EOL)
-
None
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;
|
Attachments
Issue Links
- relates to
-
MDEV-11418 AliSQL: [Feature] Issue#1 KILL IDLE TRANSACTIONS
-
- Closed
-
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?