SQLAlchemy併發寫入引發的思考

鎖

• 共享鎖 
  • 定義：共享鎖就是允許多個執行緒同時獲取一個鎖，一個鎖可以同時被多個執行緒擁有。

  • 舉例：比如有一個房間，你和你的女朋友都有要是可以進入這個房間，這就是共享鎖，這個房間是你跟你的女朋友共享的 

• 互斥鎖 
  • 定義：互斥鎖，也稱作獨佔鎖，排它鎖，一個鎖在某一時刻只能被一個執行緒佔有，其它執行緒必須等待鎖被釋放之後才可能獲取到鎖。
  • 舉例:就比如蹲廁所吧，同一時間一個茅坑由你一個人獨佔，這就叫做獨佔鎖，互斥鎖，其他人是不可以用的（當然，特殊情況除外)

• 樂觀鎖 
  • 總是假設最好的情況，每次去拿資料的時候都認為別人不會修改，所以不會上鎖，但是在更新的時候會判斷一下在此期間別人有沒有去更新這個資料，可以使用版本號機制和CAS演算法實現。樂觀鎖適用於多讀的應用型別，這樣可以提高吞吐量，像資料庫提供的類似於write_condition機制，其實都是提供的樂觀鎖。在Java中java.util.concurrent.atomic包下面的原子變數類就是使用了樂觀鎖的一種實現方式CAS實現的。 

session.Query(User).with_for_update().first()
session.Query(User).with_for_update(read=True).first()

完整形式為：

with_for_update(read=False, nowait=False, of=None)

read
是標識加互斥鎖還是共享鎖. 當為 True 時, 即 for share 的語句, 是共享鎖. 多個事務可以獲取共享鎖, 互斥鎖只能一個事務獲取. 有"多個地方"都希望是"這段時間我獲取的資料不能被修改, 我也不會改", 那麼只能使用共享鎖.
nowait
其它事務碰到鎖, 是否不等待直接"報錯".
of
指明上鎖的表, 如果不指明, 則查詢中涉及的所有表(行)都會加鎖.

補充

在用SQLAlchemy對資料庫操作的過程中出現這樣一個現象，當在session.query()時，如果之前有session.add()操作，即使尚未進行commit操作，在query時也會查詢到這個尚未真正插入資料庫的物件。這個有待探究 ，後續補充