我们在一些复杂的单元测试中使用sqlalchemy。在每次测试结束时,我们完全使用以下命令拆除数据库drop_all
。有时,有人会忘记关闭嵌入单元测试深处的会话。然后,我们必须花费大量时间试图找出问题所在,并最终关闭 sqlalchemy 会话。
我们想要一种可靠的方式来强制关闭与数据库的所有连接。我们已经尝试过了session.close_all()
,但这并没有达到我所描述的效果。
编辑:
下面是当进程挂起并尝试删除数据库时我们看到的 mysql 进程列表。大概 ID 285 是有问题的进程:
+-----+------+-----------------+----------+---------+------+---------------------------------+------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+-----+------+-----------------+----------+---------+------+---------------------------------+------------------------------+
| 172 | root | localhost | mydb | Query | 0 | init | show processlist |
| 285 | root | localhost:47147 | mydb | Sleep | 6 | | NULL |
| 289 | root | localhost:47152 | mydb | Query | 5 | Waiting for table metadata lock | DROP TABLE `mytable` |
+-----+------+-----------------+----------+---------+------+---------------------------------+------------------------------+
编辑:根据请求,我还包括事务日志:
------------
TRANSACTIONS
------------
Trx id counter 1144929
Purge done for trx's n:o < 1144827 undo n:o < 0 state: running but idle
History list length 398
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 0, not started
MySQL thread id 37, OS thread handle 0x8f46bb40, query id 776 localhost root init
show engine innodb status
---TRANSACTION 0, not started
MySQL thread id 45, OS thread handle 0x8f2ceb40, query id 774 localhost 127.0.0.1 root Waiting for table metadata lock
DROP TABLE `mytable`
---TRANSACTION 1144823, ACTIVE 12 sec
MySQL thread id 41, OS thread handle 0x8f2ffb40, query id 595 localhost 127.0.0.1 root cleaning up
Trx read view will not see trx with id >= 1144824, sees < 1144824