Welcome!

Java Authors: Corey Eng, Pat Romanski, Roger Strukhoff, Keith Cawley, Elizabeth White

Related Topics: Java

Java: Blog Feed Post

SDD Cache: Why is Cache Write Through Good?

To write through or to write back? That is the question

Whether ‘tis nobler in the mind to suffer the slings and arrows of your IT manager or to take up cache against a sea of data. With apologies to Bill Shakespeare, the IT Dog is discussing two different cache write policies: write through and write back. Let me take a run at telling you what they are, why they are different and what you need to think about when you decide what policy to use.

Cache Write Through
This is the easier to explain and understand of the two policies discussed here. Cache write through is like having your cake and eating it too. Data is written into cache for fast retrieval when needed for a future operation and at the same time, the data is written into the underlying memory location (think central database or primary storage here). Why is cache write through good? Because it insures the integrity of the data in the database so if another application needs to access the same data, you can be sure the data in the database is correct or ‘fresh’. Another benefit to cache write through is there is always a good, reliable copy of the data in the database if something happens to the cache itself (e.g. power failure). “So Dog, why wouldn’t I do cache write through all the time?” Well, because cache write through has a little problem in that the writing application must wait for the completion of the write into the primary storage before it can proceed with the next operation and as you well know, writing to primary storage can be slow which is why you are using cache in the first place. Write through cache can therefore slow down the application. So you get data integrity and assurance at the expense of application speed.

Getting Down And Dirty
We need to get a little dirty here to explain cache write back. No, not that kind of dirty; we are still talking about data and applications here. Cache write back uses cache as the temporary storage for the ‘freshest’ data and that same data is updated in the primary storage at a later time. This means that when a data location is updated, it is written to only to cache, not to primary storage and the data in cache is termed ‘fresh’. The corresponding data location in primary storage now does not match the ‘fresh’ cache data and is now considered ‘stale’. The cache controller keeps track of the state of the primary storage (fresh or stale) by using a ‘dirty’ bit to indicate if the data in the primary storage matches the cache data copy or does not. If a request for the stale data from primary storage comes in from another application, then the controller has to update the primary storage location before the application can use the data. “Why would I use this cache policy?” Well, because data is not written into slower, primary storage each time it is updated, the writing application does not have to wait for the write to primary storage to be completed before moving on to the next operation so the application runs faster. The problem with this policy is there is a small chance that the fresh cache data (or the dirty bit) can be corrupted before the data is written into primary storage. So you get speed at the expense of possible loss of data integrity.

What To Do When?
The question on which of these two cache policies to use depends on the application. Applications that absolutely cannot risk data loss (banks storing real-time trading info, continuous data protection in back store) should use write through cache policy and applications that can tolerate data loss (back end, analytics, etc.) can speed performance by using write back cache policy.

Tell Me What Your Policy Is
Let me know if you have experience with using either write back or write through cache policy and what you have learned from deploying that technique.

More Stories By Peter Velikin

Peter Velikin has 12 years of experience creating new markets and commercializing products in multiple high tech industries. Prior to VeloBit, he was VP Marketing at Zmags, a SaaS-based digital content platform for e-commerce and mobile devices, where he managed all aspects of marketing, product management, and business development. Prior to that, Peter was Director of Product and Market Strategy at PTC, responsible for PTC’s publishing, content management, and services solutions. Prior to PTC, Peter was at EMC Corporation, where he held roles in product management, business development, and engineering program management.

Peter has an MS in Electrical Engineering from Boston University and an MBA from Harvard Business School.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.