cvs commit: jakarta-slide/src/doc caching.xml

[oz...@apache.org]

ozeigermann    2003/12/02 07:17:34

  Added:       src/doc  caching.xml
  Log:
  Added initial doc on kernel level caching. This still is work in progress!
  
  Revision  Changes    Path
  1.1                  jakarta-slide/src/doc/caching.xml
  
  Index: caching.xml
  ===================================================================
  <?xml version="1.0" encoding="ISO-8859-15"?>
  WORK IN PROCESS DO NOT TRANSFORM
  <document>
  
    <properties>
          <author email="ozeigermann@apache.org">Oliver Zeigermann</author>
          <title>Kernel level caching</title>
      </properties>
  
    <body>
    
      <section name="Overview">
  
          <p>Slide provides store independent caching on the kernel level. Main features:<br/>
             <ul>
               <li>highly configurable</li>
               <li>optional content caching</li>
               <li>based on LRUMap from Jakarta commons</li>
               <li>transactional JTA support</li>
               <li>isolation level <em>read committed</em></li>
             </ul>
          </p>
  
      </section>
      <section name="How to configure?">
  
      </section>
      <section name="How does it work?">
          <p>Requirements of a cache:<br/>
             <ul>
               <li>if an entry is found it must be valid</li>
               <li>it must not grow beyond its well defined memory boundaries</li>
               <li>it must never block</li>
               <li>it should be significantly faster than the store it is caching</li>
             </ul>
          </p>
          <p>While these requirements seem to be clear at first glance and should not be too hard to accomplish, it is not that easy.
          The main thing that makes this especially difficult is Slide's full transactional support.
          This means not only the stores, but also the cache for them needs to support transactions.
          Obviously, of the well known <a hred="http://www.nusphere.com/products/library/acid_transactions.htm">ACID</a>
          transaction properties durability does not apply to caching. At least caching must not prevent the underlaying store
          from asserting the durability property.
          </p>
          <p>The cache functions in <em>write-through</em> manner. This means every write goes through to the store it caches. 
          It should be clear, this does not allow for write caching, i.e. deferring writes to the store until a well defined event occurs.
          Such a policy is generally called <em>write-back</em>. A <em>write-back</em> policy is certainly faster when more than
          one write request on the same data is performed per transaction - which actually quite regularly happens in Slide.
          On the other hand it is much more complicated which includes a high risk of incorrect data. Even if it is really properly
          implemented, still it does not allow for updates of the data from other sources than Slide. <em>write-back</em> is
          might be a feature of future Slide releases. At least a complicated spilling mechanism would be needed.
          </p>
          <p>Besides a global cache that serves most of the read access, every transaction gets a local cache of its own.
          Now every write to the caches goes through to the store, but also is stored in the transaction's local cache. 
          The same is true for deletes. Subsequent reads inside the same transaction to the same data are guaranteed 
          to either be taken from this local cache or not at all from the cache, but from the store. At commit time this
          temporary data is atomically shifted to the main cache. Remember, there is no need to update the store with 
          data from the cache as it always works in <em>write-through</em> manner. All this guarantees the cache provides 
          the isolation level <em><a href="http://www.daffodildb.com/webhelp/Transaction_Support_&_Concurrency_Levels.htm">read committed</a></em>.
          This is not that bad, but not that good as well. Unfortunately, there is no obvious way how to achive this
          without introducing locks to the cache. As the cache is not allowed to ever block, a complicated invalidation
          mechanism would have to be developed.        
          </p>
      </section>
  
      
    </body>
  
  </document>
  
  
  

---------------------------------------------------------------------
To unsubscribe, e-mail: slide-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: slide-dev-help@jakarta.apache.org