UPDATE：此錯誤已固定在Service Fabric SDK version 2.4.164 2月3日，從2017年release notes引用：可靠隊列的快照隔離被破壞了嗎？
修復到ReliableQueue正確處理額外的交易水平和組合
修復錯誤，其中ReliableQueue .GetCountAsync如果還正在閱讀您自己的寫，則不符合快照隔離。此問題最初報告於Stack Overflow。感謝您的錯誤報告。
我在寫作過程中我嘲笑的服務織物可靠的集合。我需要這些模擬模擬真實實現的交易行爲儘可能接近。
因此，我編寫了幾個測試用例，我運行這些測試用例來驗證我的模擬行爲與真正的實現類似。
但是，在一些處理快照隔離的測試案例中，我發現我的mock有不同的行爲。但仔細看後，我不太確定這個錯在我身邊。
所以我認爲我可能已經在可靠隊列如何強制快照隔離方面出現一個錯誤。
的MSDN docs快照隔離說：
交易可以識別出被交易開始前提交唯一的數據修改。在當前事務開始後由其他事務進行的數據修改對當前事務中執行的語句不可見。
和：
可信賴隊列支持讀你寫的。換句話說，對於屬於同一事務的後續讀取，事務內的任何寫入都將是可見的。
因此，執行快照隔離的操作（如GetCountAsync）應該會看到不受其他事務影響的一致快照。只有擁有快照的交易所做的更改纔可見。
確實如此，可靠的字典，但不適用於可靠的隊列。
對於可靠隊列（通過做GetCountAsync或CreateEnumerableAsync）拍攝的快照確實不受其他事務所做修改的影響，但前提是我們自己不做任何更改。這樣做不僅會使我們自己的更改顯示在快照中，而且還會暴露其他事務的更改。
下面的代碼片段可以被放入一個可靠的服務，以重現此：
public async Task Verify_that_reliable_queue_snapshot_isolation_is_broken()
{
// Get an empty reliable queue
var name = Guid.NewGuid().ToString();
var queue = await this.StateManager.GetOrAddAsync<IReliableQueue<string>>(name);
// Start transaction and take a snapshot by getting queue count
var t1 = this.StateManager.CreateTransaction();
Assert.AreEqual(0, await queue.GetCountAsync(t1)); // ok
// Enqueue something in a concurrent transaction
using (var t2 = this.StateManager.CreateTransaction())
{
await queue.EnqueueAsync(t2, "something");
await t2.CommitAsync();
}
// Snapshot should still say zero
Assert.AreEqual(0, await queue.GetCountAsync(t1)); // ok
// Enqueue something else in the first transaction
await queue.EnqueueAsync(t1, "something else");
// Count should now be 1 in t1, but it's actually 2.
Assert.AreEqual(2 /* should be 1*/, await queue.GetCountAsync(t1)); // broken!
}
我需要知道這是否是由設計，和文檔不正確，或者這是否是一個錯誤。或者如果我誤解了某些東西。
任何反饋意見。