Using write behind and high availability

Question

If I have a write behind cache which is also "high availability", will the write get fired only once even though the data exists twice in app fabric? (The data is written twice in app fabric.)<o:p></o:p>

If the write event is only fired once, what happens when one node fails? Is app fabric robust enough to ensure that uncommitted writes will still get triggered?<o:p></o:p>

I am looking to use app fabric as a queue for sql writes.   I am hoping that I can design an app fabric layer that is just as reliable as sql server.

Answer 1

If I have a write behind cache which is also "high availability", will the write get fired only once even though the data exists twice in app fabric? (The data is written twice in app fabric.)<o:p></o:p>

[No. The data is only written once to the Db. One of the nodes acts as a primary for a specific data and would be the only one who writes this data.]

If the write event is only fired once, what happens when one node fails? Is app fabric robust enough to ensure that uncommitted writes will still get triggered?<o:p></o:p>

[When a node fails, there is a new primary which gets elected. It is possible that he might send some values again which he wasn't sure whether the last node wrote succesfully before going down. The store needs to be idempotent to be able to handle this. The Cache ensures that in all such cases the data makes it to the db. However, if 2 or more nodes fail at the same time , then you would potentially loose data and you need to be able to handle that. ]

I am looking to use app fabric as a queue for sql writes.   I am hoping that I can design an app fabric layer that is just as reliable as sql server.

[Cool, could you provide some more details on the scenario that you are trying. One of the additional benefits of cache fronting the Db as a queue would be that operations on the same Key would get coalesced into a single write operation before they go to the db.

Again, I would like to reiterate - Cache is an in memory store and as a concept itself, it does not ensure extreme availability. It is your responsibility to make sure that in the worst case if multiple nodes go down, there is a backup mechanism to ensure data is not lost. ]

Answer 2

Thanks for the detailed reply. <o:p></o:p>

Is there a way to make the write behind provider synchronous? The main purpose of the write behind queue is to open up the possibility of taking sql offline for writes.   In general we do not require the queue to buffer writes. When we want to take sql offline, we would change a configuration setting to make he writes asynchronous.  Writing asynchonously ONLY when we are maintaining the sql box would reduce our exposure to multiple cache nodes failing.

The diagram below is based on the assumption that we are not coding for two simultaneous node failures. If I have to code for that, in memory queues are out of the question.<o:p></o:p>

Answer 3

Have you heard of Write-Through Provider?  Did you try to use that model?

Thanks,

Laxmi Narsimha Rao Oruganti

---

Please hit "Yes", if my post answered your question(s). All postings are as-is and confer no rights.

Answer 4

The write-behind provider is asynchronous to help improve application latency and throughput. You could trying tweaking the value of WriteBehindInterval to see if a smaller interval serves your purpose. For times when SQL is offline, consider using an appropriate value of WriteBehindRetryCount to ensure that items are retained until they're successfully written.

-Arijit