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="[EMAIL PROTECTED]">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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
