On Wed, 9 Apr 2008, Tobias Schlitt wrote:
> On 04/09/2008 02:13 PM Derick Rethans wrote:
> > On Mon, 7 Apr 2008, Tobias Schlitt wrote:
>
> >> - **Bubbling restored data up through the cache stack**
> >> According to the replacement strategy, cache items need to be placed into
> >> higher levels of the hierarchy, as soon as they get restored from a
> >> deeper
> >> level, to make them available faster on subsequent restore requests. For
> >> more
> >> information see the `Replacement strategies`_ section.
>
> > Sometimes you might not want the items stored in a higher stack level,
> > for example because of data size reasons. As an example, you want a 1mb
> > PDF file stored in a cache on disk, but definitely not in the memory
> > cache. How are we going to handle this?
>
> You need to create a dedicated cache storage for these files.
Why? I'm saying that this should be an option of every cache storage
that we have. Creating a whole new storage backend for just doing this
seems silly. I think it's particulary important for the memory caches
(in-memory, apc, shared-mem).
> > I think we should not implement this at all, but just the "Propagate on
> > store" variant. It can also make things simpler in the API and thus
> > provide more performance.
>
> I also thought about this and agree with you. We can then leave the
> complete storage strategy class layer. I will still keep my eyes open
> during implementation to allow us a possible implementation for later.
Yeah, let's do that then.
> >> ezcCacheStack
> >> -------------
> >>
> >> An object of the ezcCacheStack class is the main instance to provide the
> >> hierarchical stack mechanism. The stack object takes care of managing
> >> several
> >> cache storages, the unified access for storing and restoring cache items
> >> and
> >> the associated objects needed to realize this.
>
> > [snip]
>
> >> class ezcCacheStack extends ezcCacheStorage
> >> {
> >> public function __construct( $location, $options );
> >> public function store( $id, $data, $attributes = array() );
> >> public function restore( $id, $attributes, $search );
> >> public function delete( $id, $attributes, $search );
> >> public function countDataItems( $id, $attributes );
> >> public function getRemainingLifetime( $id, $attributes );
> >>
> >> public function getStackedCaches();
> >> }
>
> > I miss a method to add a new storage to the stack. I know you mention
> > this as an option in "ezcCacheStackOptions", but I don't think this fits
> > as an option easily. I would go for a method that adds a new storage
> > configuration to the bottom of the "stack" here.
>
> I don't see the sense here. In general you want to configure the stack
> once and be happy to never change it. Could you give me an example of a
> use case of such a method?
Sure, I think it's just simpler to use then a deeply nested options
array:
<?php
$stack = new ezcCacheStack();
$options = $stack->options = new ezcCacheStackOptions;
$apcOptions = new ezcCacheStackStorageConfiguration;
$apcOptions->class = 'ezcCacheStorageApcPlain';
$apcOptions->itemLimit = 512;
$memCacheOptions = new ezcCacheStackStorageConfiguration;
$memCacheOptions->class = 'ezcCacheStorageMemcachePlain';
$memCacheOptions->location = '27.0.0.1';
$memCacheOptions->itemLimit = 1024;
$fileOptions = new ezcCacheStackStorageConfiguration;
$fileOptions->class = 'ezcCacheStorageFileArray';
$fileOptions->location = '/var/cache/foo';
$options->storages = array(
$apcOptions,
$memCacheOptions,
$fileOptions
);
?>
vs.:
<?php
$stack = new ezcCacheStack();
$stack->addStorage( 'ezcCacheStorageApcPlain', null, 512 /*, $extraOptions */ );
$stack->addStorage( 'ezcCacheStorageMemcachePlain', 'localhost', 1024 );
$stack->addStorage( 'ezcCacheStorageFileArray', '/var/cache/foo' );
?>
> >> interface ezcCacheStackableStorage
> >> {
> >> restoreMetaInfo();
> >> storeMetaInfo( array $metaInfo );
> >>
> >> purge();
>
> > Maybe we can add an option to purge() to clear out the whole cache?
>
> I would suggest to add another method for this, named empty() or something.
You can't really use empty() though, as it's most likely a reserved
keyword.
> >> ezcCacheStackOptions
> >> --------------------
> >>
> >> An object of this class is used to configures the cache stack. It extends
> >> the
> >> ezcCacheStorageOptions class, to be compatible with all other mechanisms.
> >> The
> >> 'ttl' and 'extension' options are ignored, because each of the stacked
> >> caches
> >> must be able to implement its own set of options. The following options are
> >> part of this class:
> >>
> >> 'storageStrategy'
> >> This option contains a class name, which is to be instantiated to
> >> perform
> >> storage operations in the stack. The class must extend the abstract
> >> ezcCacheStackStorageStrategy class.
> >> 'storages'
> >> This option is an array of ezcCacheStackStorageConfiguration objects,
> >> that
> >> will be used to define the cache storages contained in the stack. Per
> >> default, no storages will be defined. In this case, a call to any of
> >> the
> >> methods defined by ezcCacheStorage will result in an exception.
>
> > I don't think we should either of those options. As I just mentioned,
> > storages should be maintained through methods and the first one,
> > storageStrategy I suggest not to have at all to make the implementation
> > easier. That means no different stack-storage-strategies.
>
> If we go this way, we cannot support the delayed initialization
> mechanism provided by ezcCacheManager for the stack. If this is ok, I
> don't have a problem with it. ezcCacheStack would then not extend
> ezcCacheStorage and we can design the API for it new from scratch.
Why not? With the example above you can still store the parameters for
all the storage backends in an array - but it's just not part of the
options class, but just ezcCacheStack.
> > If $meta would be an object, or returned by reference, there would be no
> > need for storeMetaInfo() right here.
>
> I think we should keep it. The problem is that we need to restore the
> meta info every time and store it again while the storage is locked. If
> we obtain the storeMetaInfo() methods, there is no chance for the
> storage to see when it needs to be stored again, except to automatically
> store it inside unlock(). This is quite dirty and untransparent, so I
> prefer to keep the calls.
Yup, good point.
> > One thing that I miss in the design is the performance impact on
> > restoring items from the cache, perhaps you could add something about
> > that?
>
> You mean the overhead in using the stack at all?
Yes.
regards,
Derick
--
Derick Rethans
eZ components Product Manager
eZ systems | http://ez.no
--
Components mailing list
[email protected]
http://lists.ez.no/mailman/listinfo/components
