原则 1.2:使用 postDelete 删除文件系统上的相关文件——具有事务支持
这个问题是这个问题的一种扩展:
执行在 Symfony/Doctrine 中删除记录时进行一些清理
我正在这样做,并且工作正常,除了一个问题:如果删除失败并且事务从未提交,则 postDelete 方法仍然运行并且文件被删除反正。
避免这种情况的好方法是什么?
This question is a sort of extension to this question:
Perform some cleanup when deleting a record in Symfony/Doctrine
I'm doing this and it's working fine, except for one problem: if the delete fails and the transaction is never committed, the postDelete method still runs and the files are deleted anyway.
What would be a good way to avoid this?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
如果您只需要在事务实际提交时触发某些操作,则需要将其在 postDelete 中排队,然后在 postTransactionCommit 处理程序中执行它,
我通常使用单例来存储队列并静态获取它。如果您使用多个连接,您将需要多个队列。
上面的提交处理程序仅在最外层提交时触发,这就是 Doctrine 与 mysql 一起工作的方式,因为它不提供嵌套事务。如果您的数据库提供嵌套事务,并且学说支持这一点,您可能需要更改它。
If you need to trigger something only when the transaction has actually been committed, you need to queue it in postDelete, and then perform it in a postTransactionCommit handler
I've typically used a singleton to store the queue and fetched it statically. If you are using multiple connections, you'll want to have multiple queues.
The commit handler above only fires on the outermost commit, which is how Doctrine works with mysql, since it doesn't provide nested transactions. If your database provides nested transactions, and doctrine supports that, you might need to change that.