我正在使用亞馬遜的SimpleDB爲iPhone遊戲製作一個簡單的高分數據庫，並遇到一些奇怪的問題，其中SimpleDB的響應消息似乎並不排隊與我發送的請求，甚至服務器上的數據狀態。亞馬遜SimpleDB：響應消息不同意請求參數
在應用程序提交高分事件的預期順序是：
一個PutAttributes請求創建 試圖用新的價值，但只有當 它是更大的覆蓋當前 比分比最後所知的 值得分。
如果期望值與服務器上的值不匹配，SimpleDB的響應消息讓應用程序知道實際值是什麼，並使用它作爲新的期望值創建新的請求。
這個過程一直持續，直到 的答覆中說，一切 是確定或直到 比分服務器恢復爲比 分數越高，我們正在試圖提交 （即如果某人具有較高 而這 來回得分提交是怎麼回事）
（如果這是有關我使用ASIHTTPRequest類來處理請求，我已經明確每個請求的緩存策略設置爲關閉緩存ASIIgn oreCachePolicy當我創建它們。）
然而，所發生的情況是有點怪......
的第一個反應回來與預期的結果。例如，該應用程序提交200分，並預計服務器上的分數爲0，但實際上爲100. SimpleDB迴應稱條件檢查失敗，並讓應用程序知道服務器上的實際值（100）。
該應用程序發送一個更新期望值的請求，但即使期望值發生了變化，SimpleDB也會以相同的響應進行響應（例如響應說實際值爲100，並且我們傳遞的期望值即使我們剛剛將它更改爲100）也是0。
該應用程序發送具有完全相同的得分/預期值作爲第二請求的第三請求（例如，100爲兩者）和SimpleDB的報告該狀態再次失敗，因爲實際值爲200
因此，即使SimpleDB報告失敗並給出了我傳入的參數的錯誤說明，但看起來第二次嘗試實際上仍然有效。這種奇怪的行爲也非常一致 - 每次我嘗試用預期值更新分數時與服務器上發生的完全相同的序列不匹配。
我一直在這裏搔着頭一陣子，現在我完全沒有想法，所以如果有人比我有更多的SimpleDB經驗可以對此有所瞭解，我會非常感激。
下面是一個請求和響應的示例序列，以方便描述情況比我上面的折磨解釋做得更好（這些值取自實際的請求和響應，但我已經編輯了不相關的部分請求）。
請求1
（在服務器上的分數是100在這一點上）
Attribute.1.Name =分數
Attribute.1.Replace =真
Attribute.1.Value = 200
Expected.1.Name =分數
Expected.1.Value = 000
一致=真
響應1
有條件檢查失敗。屬性（分數）值（100），但預期（000）
請求2
（該應用程序的更新，以適當的分數，但基於響應SimpleDB中似乎忽略的變化）
屬性。 1.Name =分數
Attribute.1.Replace =真
Attribute.1.Value = 200
Expected.1.Name =分數
Expected.1.Value = 100
一致=真
響應2
有條件檢查失敗。屬性（分數）值（100），但預期（000）
要求3
（這一次的SimpleDB得到的預期值正確，但還報告說，即使所有先前的響應另有說明，比分一直更新）
Attribute.1.Name =分數
Attribute.1.Replace =真
Attribute.1.Value = 200
Expected.1.Name =分數
Expected.1.Value = 100
一致性=真
響應3
有條件檢查失敗。屬性（分數）值（200），但預期（100）
更新（10年10月21日）
我檢查，以確保正在從服務器返回的requestIDs都是獨一無二的，他們確實是。