選擇更新行爲

我已經很好地理解了使用SELECT FOR UPDATE和發生另一個SELECT/UPDATE時發生的有關行更新的情況。但是當SELECT FOR UPDATE發生兩個請求時會發生什麼。選擇更新行爲

例如：

線程A 啓動事務和做了一個SELECT FOR UPDATE上一行並檢索一些信息並開始，需要時間的HTTP請求。電話回覆後交易已完成並且會話關閉。
線程B，當A等待請求時，開始一個新的事務，並在同一行執行SELECT FOR UPDATE。它是否會檢索信息並繼續處理HTTP請求，或者是否等待線程A提交/執行更新，然後從該行中檢索數據。

我不在乎一旦請求返回並且更新表的時間到來會發生什麼。第二個更新將會拋出或更新該行上的最後一個可能的數據。

但實際的HTTP請求是否會由他們兩個完成？換句話說，在這種情況下，可以使用（濫用）SELECT FOR UPDATE作爲線程同步機制嗎？

來源

2015-04-21 idipous

您正在混合圖層。 PostgreSQL不會執行HTTP。 SELECT ... FOR UPDATE與HTTP無關。

下面是它如何工作的：

第一節確實BEGIN
會議2確實BEGIN
第一節確實SELECT ... FOR UPDATE，並得到一個或多個行
會議2確實SELECT ... FOR UPDATE和比賽之一相同的行，所以它塊，不返回任何東西，直到...
會話1做了COMMIT或ROLLBACK
會話2得到從早先的SELECT ... FOR UPDATE

換句話說結果，鎖定持續時間由事務邊界控制。交易邊界所在取決於您的應用程序和框架，在您未以任何方式識別的數據庫層以上的東西位置。

（此外，這與線程無關）。

來源

2015-04-21 09:50:14

謝謝你克雷格。是的，我知道線程和Http與PostgreSQL無關。也許我沒有正確表達自己。但是，你回答了我的問題。會話2阻止其執行，直到會話1已提交纔會繼續。因此，它不會前進到SELECT FOR UPDATE之後存在的HTTP調用，直到會話1提交更改。我對麼？ – idipous

@idipous正如我所說，不可能回答這個問題，因爲我不知道你在使用什麼框架，它如何管理事務等等。這取決於應用程序何時提交。就這些。所以你必須弄清楚應用程序何時提交。聽起來，根據您的編輯，就像事務在整個與客戶端的HTTP交換中保持開放一樣，在這種情況下，是的，它會阻止會話B繼續，直到會話A返回。這一切都取決於你何時提交。 –

我編輯了我的問題以清除事務開始和提交點。 – idipous

選擇更新行爲

回答

相關問題