为什么 django 在 mysql 中留下锁？
我有一个 Django 应用程序，它使用 MySQL 和 InnoDB 引擎进行存储。由于某些原因，Django 有时会保留锁，即使在查询完成后也是如此。 （我可以用 Innotop 看到它们）。
我在代码中执行的唯一事务处理操作是为我正在处理多表继承的某些 save() 方法指定了 django.db.transaction.commit_on_success 。
如果我重新启动 Apache 服务器，锁就会消失。
有人见过这样的东西吗？我是否可以编写一些会导致这种情况的反模式？
I have a Django app that uses MySQL and the InnoDB engine for storage. For some reason, Django sometimes leaves locks in place, even after the query has completed. (I can see them with Innotop).
The only transaction-handling stuff that I do in my code is that I have django.db.transaction.commit_on_success specified for some of my save() methods where I am working with multi-table inheritance.
If I restart the Apache server, the locks go away.
Has anyone seen something like this? Could I have written in some anti-pattern that would cause this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
我唯一一次成功做到这一点是通过在 Django 中设置与请求/视图无关的“计划”任务。默认的自动提交事务处理系统仅在请求/响应对完成并将其发送回最终用户时提交事务，因此创建在不发送请求的情况下运行的 kron 式作业会绕过该机制。
否则通常很难让它无法释放锁。您确定没有非常长时间运行的代码块（可能依赖于超时或类似的外部服务）将事情捆绑起来？
The only time I've managed to accomplish this was by setting up "scheduled" tasks in Django that weren't related to requests/views. The default auto-commit transaction handling system only commits transactions when a request/response pair is completed and sent back to the end user, so creating kron-esque jobs that run without a request being sent bypasses that mechanism.
Otherwise it's generally pretty difficult to make it fail to release a lock. You're sure there aren't extremely long-running blocks of code (perhaps relying on an external service that's timing out or something of the sort) tying things up?