RavenDB returns stale results after deletion

Question

We seem to have confirmed that RavenDB is getting outdated results even when we use the various WaitForNonStaleResults options. Below is a fully functional sample code (written as a standalone test so that you can copy / paste it and run it as it is).

public class Cart { public virtual string Email { get; set; } } [Test] public void StandaloneTestForPostingOnStackOverflow() { var testDocument = new Cart { Email = " [e-mail] " }; var documentStore = new EmbeddableDocumentStore { RunInMemory = true }; documentStore.Initialize(); using (var session = documentStore.OpenSession()) { using (var transaction = new TransactionScope()) { session.Store(testDocument); session.SaveChanges(); transaction.Complete(); } using (var transaction = new TransactionScope()) { var documentToDelete = session .Query<Cart>() .Customize(x => x.WaitForNonStaleResultsAsOfLastWrite()) .First(c => c.Email == testDocument.Email); session.Delete(documentToDelete); session.SaveChanges(); transaction.Complete(); } RavenQueryStatistics statistics; var actualCount = session .Query<Cart>() .Statistics(out statistics) .Customize(x => x.WaitForNonStaleResultsAsOfLastWrite()) .Count(c => c.Email == testDocument.Email); Assert.IsFalse(statistics.IsStale); Assert.AreEqual(0, actualCount); } } 

We tried every taste of WaitForNonStaleResults and no change. Waiting for results without obsolescence seems to work fine for an update, but not for deletion.

Update

Some things I tried:

• Use separate sessions for each action. Result: no difference. The same successes and failures.

• Place Thread.Current.Sleep(500) before the final request. Result: success. If I sleep a thread for half a second, the count returns zero, as it should.

Answer 1

Re: my comment above is about obsolete results, AllowNonAuthoritiveInformation does not work. We need to put WaitForNonStaleResults in each request, which is the usual "answer" to this problem, it feels like a massive "code smell" (as far as I usually hate this term, it seems quite appropriate here).

The only real solution I have found so far:

 var store = new DocumentStore(); // do whatever store.DatabaseCommands.DisableAllCaching(); 

Performance suffers accordingly, but I think slower performance is far less sinful than unreliable, if not overt, inaccurate results.

Answer 2

This is an old question, but I recently ran into this problem. I managed to get around this by changing the convention to the DocumentStore used by the session to make it wait for obsolescence with the last entry:

 session.DocumentStore.DefaultQueryingConsistency = ConsistencyOptions.AlwaysWaitForNonStaleResultsAsOfLastWrite; 

This made it so that I did not have to configure every request run after. However, I believe this only works for queries. This definitely does not work with patches, as I found out through testing.

I would also be careful about this and just use it around the necessary code, as this can cause performance problems. You can return the default storage to the default:

 session.DocumentStore.DefaultQueryingConsistency = ConsistencyOptions.None; 

Answer 3

The problem is not related to deletion; it is related to using TransactionScope . The problem here is that the DTC transaction is asynchronous.

To fix this problem you need to call:

  session.Advanced.AllowNonAuthoritiveInformation = false; 

This will force RavenDB to wait for the transaction to complete.