Re: cvs commit: jakarta-turbine-stratum/src/test/org/apache/stratum/jcs TestDiskCache.java

[James Taylor <jt...@4lane.com>]

>   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:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>

RE: cvs commit:jakarta-turbine-stratum/src/test/org/apache/stratum/jcs TestDiskCache.java

[Aaron Smuts <aa...@verizon.net>]

Sounds like what I want to do for the lateral, but the lateral has
another part.  The disk is just a service.

The lateral needs both a listener and a service.  The listener recives
and the service handles broadcasts.  There are interfaces for both.
There will be a core LateralCacheAttributes and the specific lateral
implementations can have both.  Instead of having multiple server types
in the config there will be one servers list and one local listening
port.  The factory will create a service for each server.

I'll do it this week.

Aaron

> -----Original Message-----
> From: James Taylor [mailto:jtaylor@4lane.com]
> Sent: Sunday, February 24, 2002 3:01 PM
> To: Turbine Developers List
> Subject: Re: cvs commit:jakarta-turbine-
> stratum/src/test/org/apache/stratum/jcs TestDiskCache.java
> 
> >   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.IndexedDiskCach
eD
> river"/>
>       <attributeSet>
>         <diskPath>bin/test/indexed-disk-cache</diskPath>
>       </attributeSet>
>     </disk>
> 
>     <disk name="hsqlDiskCache>
>       <driver
>
className="org.apache.stratum.jcs.auxiliary.disk.hsql.HSQLDiskCacheDrive
r"
> />
>       <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.JISPDiskCacheDrive
r"
> />
>       <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:turbine-dev-
> unsubscribe@jakarta.apache.org>
> For additional commands, e-mail: <mailto:turbine-dev-
> help@jakarta.apache.org>



--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>