這種奇怪的行爲可以通過App Engine Datastore上的最終一致性來解釋嗎？

我已經實現了兩個服務器端HTTP端點，它們1）存儲一些數據並2）處理它。方法1）調用方法2）到App Engine Tasks，因爲它們是耗時的任務，我不希望客戶端等待。該過程如下圖所示。這種奇怪的行爲可以通過App Engine Datastore上的最終一致性來解釋嗎？

現在從我不時體驗嘗試的過程，當處理任務（在下面的序列圖命名processSomething）無法找到數據 - 與下面的黃色throw WtfException()所示。這可以用最終一致性模型described here來解釋嗎？

該文檔說強讀取一致性爲，但寫入最終一致性。我不確定這件事到底意味着什麼。任何澄清表示讚賞。

enter image description here

編輯：我意識到我問一個布爾的問題在這裏，但我想我在尋找一個答案備份一些文件是什麼最終一致性是普遍，特別在谷歌數據存儲

編輯2：通過請求下面是實際的讀/寫操作的詳細信息：

寫操作：

entityManager.persist(hand); 
entityManager.close()

我正在使用JPA進行數據持久性。對象「手」從客戶端接收，並且以前未存儲在數據庫中，因此將分配新的密鑰Id。

讀操作：

SELECT p FROM Hand p WHERE p.GameId = :gid AND p.RoundNo = :rno

既不GameId也不RoundNo是主鍵。 GameId是一個「外鍵」，雖然數據存儲設計沒有注意到這一點。

2013-04-18 Nilzor

如果您加載（ID）的關鍵，我認爲你應該得到更新的實體。來自doc「因爲數據存儲獲取和祖先查詢在執行之前應用了任何未完成的修改，所以這些操作始終能夠看到所有先前成功事務的一致視圖。這意味着get操作（通過鍵查找更新的實體）可以保證看到該實體的最新版本。「 – marcadian

這將有助於如果你表現出實際的代碼，向您展示如何保存實體以及如何找回它，但假設id是一個實際的數據存儲ID，一個關鍵的組成部分，你的load是get使用id而不是query對其他財產，然後最終一致性不是你的問題。

2013-04-18 20:16:55 Greg

我已經更新了有關db交互代碼細節的問題。正如你所看到的，你的假設都是錯誤的，但我想可以推斷出主要答案是對我的問題**是**：最終一致性*可能是這裏的問題。同意？ – Nilzor

是的，這絕對是一個候選人。 – Greg

回答