|
|
|
@ -26,22 +26,23 @@ package com.iluwatar.caching;
|
|
|
|
|
*
|
|
|
|
|
* The Caching pattern describes how to avoid expensive re-acquisition of resources by not releasing
|
|
|
|
|
* the resources immediately after their use. The resources retain their identity, are kept in some
|
|
|
|
|
* fast-access storage, and are re-used to avoid having to acquire them again. There are three main
|
|
|
|
|
* caching strategies/techniques in this pattern; each with their own pros and cons. They are:
|
|
|
|
|
* fast-access storage, and are re-used to avoid having to acquire them again. There are four main
|
|
|
|
|
* caching strategies/techniques in this pattern; each with their own pros and cons. They are;
|
|
|
|
|
* <code>write-through</code> which writes data to the cache and DB in a single transaction,
|
|
|
|
|
* <code>write-around</code> which writes data immediately into the DB instead of the cache, and
|
|
|
|
|
* <code>write-around</code> which writes data immediately into the DB instead of the cache,
|
|
|
|
|
* <code>write-behind</code> which writes data into the cache initially whilst the data is only
|
|
|
|
|
* written into the DB when the cache is full. The <code>read-through</code> strategy is also
|
|
|
|
|
* included in the mentioned three strategies -- returns data from the cache to the caller <b>if</b>
|
|
|
|
|
* it exists <b>else</b> queries from DB and stores it into the cache for future use. These
|
|
|
|
|
* strategies determine when the data in the cache should be written back to the backing store (i.e.
|
|
|
|
|
* Database) and help keep both data sources synchronized/up-to-date. This pattern can improve
|
|
|
|
|
* performance and also helps to maintain consistency between data held in the cache and the data in
|
|
|
|
|
* the underlying data store.
|
|
|
|
|
* written into the DB when the cache is full, and <code>cache-aside</code> which pushes the
|
|
|
|
|
* responsibility of keeping the data synchronized in both data sources to the application itself.
|
|
|
|
|
* The <code>read-through</code> strategy is also included in the mentioned four strategies --
|
|
|
|
|
* returns data from the cache to the caller <b>if</b> it exists <b>else</b> queries from DB and
|
|
|
|
|
* stores it into the cache for future use. These strategies determine when the data in the cache
|
|
|
|
|
* should be written back to the backing store (i.e. Database) and help keep both data sources
|
|
|
|
|
* synchronized/up-to-date. This pattern can improve performance and also helps to maintain
|
|
|
|
|
* consistency between data held in the cache and the data in the underlying data store.
|
|
|
|
|
* <p>
|
|
|
|
|
* In this example, the user account ({@link UserAccount}) entity is used as the underlying
|
|
|
|
|
* application data. The cache itself is implemented as an internal (Java) data structure. It adopts
|
|
|
|
|
* a Least-Recently-Used (LRU) strategy for evicting data from itself when its full. The three
|
|
|
|
|
* a Least-Recently-Used (LRU) strategy for evicting data from itself when its full. The four
|
|
|
|
|
* strategies are individually tested. The testing of the cache is restricted towards saving and
|
|
|
|
|
* querying of user accounts from the underlying data store ( {@link DbManager}). The main class (
|
|
|
|
|
* {@link App} is not aware of the underlying mechanics of the application (i.e. save and query) and
|
|
|
|
|