什麼類型的請求可以成爲`@ transaction.non_atomic_requests`的良好候選者？

Question

在網絡上處理transactions的常用方法是將每個請求包裝在一個事務中。在Django中，您可以在要爲其啓用此行爲的每個數據庫的配置中將ATOMIC_REQUESTS設置爲True。

它的工作原理是這樣的。在調用視圖函數之前，Django啓動一個事務。如果響應沒有問題產生，Django就承諾交易。如果視圖產生異常，Django會回滾事務。

雖然這種交易模式的簡單性很吸引人，但它也使得流量增加時效率低下。爲每個視圖打開一個事務有一些開銷。

對於不需要包裝在transactions中的請求，您可以申請@transaction.non_atomic_requests裝飾器。

給定一個包含多個View類和請求方法的Django view.py。我該如何決定哪些請求會成爲非原子裝飾器的優秀候選者？

什麼「陷阱」可能潛伏？

我看得出POST方法不與.save()製作好的候選人或任何東西，但我還需要注意的事項？

Answer 1

不幸的是，我不認爲有很多通常適用的提示，技巧等等。問題是：考慮到我可能執行的所有數據庫操作，這個操作序列是否需要數據庫事務正常工作？如果答案是肯定的（或者你不確定），則使用交易;如果沒有，不要。

這是一個非常特定於應用程序的問題。以您爲例，有很多情況下，save()需要交易，許多情況下不需要交易。我不知道任何替代品只是坐下來思考可能性。

最重要的是要很好地理解數據庫事務，特別是isolation levels。人們常常錯誤地認爲他們對某些併發問題是安全的，因爲他們的事務心智模型匹配SERIALIZED隔離級別，實際上他們的操作使用READ COMMITTED（Django默認）。

理解和考慮除了普通事務之外可以使用的其他可用工具也很重要，例如鎖定（例如Django的select_for_update()）和樂觀併發。