> I decided to extract an abstract superclass for consistency with the current
> code, however my feeling now is that composition rather than inheritence, ie
> some kind of plugin architecture, would be better for disk caches, more along
> the lines of the way lateral caches work. More on that later.
With the AbstractDiskCache all one needs to do to implement a DiskCache
is extend it and implement the methods that actually modify the
underlying persistent store. This works well, but there is actually
quite a bit more work involved since you need to implement a factory and
manager, and possibly even a CacheAttributes, for each subclass.
I think a better model would be to implement a concrete DiskCache, with
a manager and factory, which uses a plugin for access to the underlying
store. At configuration time you would configure what plugin to use by
providing a class name. I think the lateral cache could be refactored
similarly (rather than providing a token that the code maps to a class,
you can just provide the class name, which reduces compile time
coupling).
I could see a cache configuration like this (just the disk auxiliaries):
<disk name="indexedDiskCache>
<driver
className="org.apache.stratum.jcs.auxiliary.disk.indexed.IndexedDiskCacheDriver"/>
<attributeSet>
<diskPath>bin/test/indexed-disk-cache</diskPath>
</attributeSet>
</disk>
<disk name="hsqlDiskCache>
<driver
className="org.apache.stratum.jcs.auxiliary.disk.hsql.HSQLDiskCacheDriver"/>
<attributeSet>
<diskPath>bin/test/jisp-disk-cache</diskPath>
<clearOnStart>false</clearOnStart>
</attributeSet>
</disk>
<disk name="jispDiskCache>
<driver
className="org.apache.stratum.jcs.auxiliary.disk.jisp.JISPDiskCacheDriver"/>
<attributeSet>
<diskPath>bin/test/hsql-disk-cache</diskPath>
</attributeSet>
</disk>
Where the manager would store the plugin and attributes for each named
disk auxiliary, and use them when caches are requested. This reduces the
number of classes to implement multiple disk caches quite a bit.
Thoughts?
Thanks,
James
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
