Skip to end of metadata
Go to start of metadata

Overview

Read Through

Generally we would recommend using Read-Through Caching.

  1. The client(s) go to Coherence looking for a value.
  2. If it is not there, Coherence locks the key 
  3. The Coherence Worker thread goes to the database and loads the value
  4. Everyone is returned the value

Error rendering macro 'gliffy' : java.lang.NullPointerException

Cache Aside

Coherence Cache Aside has very bad press (my friend Lewis Foti once offered to shoot anyone who used it again (wink) ).  

  1. The client goes to Coherence looking for a value
  2. If a NULL value is returned to the client it loads from the database
  3. The client then puts the value returned into Coherence

Error rendering macro 'gliffy' : java.lang.NullPointerException

 Cache-Aside is usually chosen for two reasons:

  • Database code is written in C#, Read-Through code needs to be written in Java, so Cache-Aside is used.
  • Legacy.  Cache-Aside has been used an the technical debt of moving to Read-Through is too high

Problem

Consider now the case where you have 6000 Grid clients (we have this scenario).  The cluster starts up and all the clients try and download the currency rates.  Suddenly you see 6000 hits on the database table and the database falls over.

Error rendering macro 'gliffy' : java.lang.NullPointerException

This problem does not occur with ReadThrough since Coherence has a lock and only one client goes to the database at a time per key.

Pattern

  1. Use a WrapperNamedCache to intercept all calls to GET
  2. Use an EntryProcessor or Trigger 
  3. If Coherence sees a NULL value it sets the value to LOADING with a TTL (say 10s) and returns a LOAD command to the client
  4. The client loads from the database and sets the value in Coherence
  5. Other clients (say 6000) receive the command LOADING and retry (say in 500ms) - they do NOT hit the database
  6. If the client dies the load will postpone for TTL (say 10s) then the next client that hits will go back to point 3 until someone successfully loads the value
  7. Everyone now gets the correct value

This is a Polling solution which is not ideal and will, of course, see an unnecessary initial extra wait on average of RETRY/2 (250ms?), tho the Database load may take a few seconds.

However, the benefits are significant (ie. the 6000 clients do not backup and starve the Service)

Psuedocode

You can do clever things with returning BinaryValues if you know what you are doing to avoid a serialization loop

Red Herring

I tried a solution using a blocking EntryProcessor.  Unfortunately, this causes thread starvation on the Server see Non-proliferation of Coherence Services

Thanks

To Nick Funnell and Toyin Akin for their input on this.

TOC