哪些类型的请求适合`@transaction.non_atomic_requests`？

Question

在 Web 上处理 transactions 的常用方法是将每个请求包装在事务中。在 Django 中，您可以在要启用此行为的每个数据库的配置中将 ATOMIC_REQUESTS 设置为 True。

它是这样工作的。在调用视图函数之前，Django 会启动一个事务。如果生成的响应没有问题，Django 将提交事务。如果视图产生异常，Django 会回滚事务。

虽然这种交易模型的简单性很有吸引力，但它也会在流量增加时变得低效。为每个视图打开一个事务有一些开销。

对于不需要包装在transactions 中的请求，您可以应用@transaction.non_atomic_requests 装饰器。

给定一个带有多个视图类和请求方法的 Django view.py。我该如何决定哪些请求可以成为非原子装饰器的良好候选者？

可能潜伏着什么“陷阱”？

我可以看到 POST 方法无法成为优秀的候选人或任何带有 .save() 的东西，但我还应该注意什么？

Answer 1

不幸的是，我认为没有多少提示、陷阱等普遍适用。问题只是：考虑到我可能执行的所有数据库操作，这一系列操作是否需要数据库事务才能正常工作？如果答案是肯定的（或者您不确定），请使用交易；如果没有，不要。

这是一个非常特定于应用程序的问题。以您的示例为例，在许多情况下save() 将需要事务，而在许多情况下则不需要。我不知道有什么可以代替坐下来思考各种可能性的方法。

最重要的是要很好地理解数据库事务，尤其是isolation levels。人们经常错误地认为他们可以避免一些并发问题，因为他们的事务心理模型匹配SERIALIZED 隔离级别，而实际上他们的操作使用READ COMMITTED（Django 默认）。

了解和考虑除了普通事务之外可以使用的其他可用工具也很重要，例如锁（例如 Django 的 select_for_update()）和乐观并发。