Okay, let me see if I have a handle on the configuration needs. It seems
that there are currently two sets of objects which need to be
configured. First, the regions which are available in the cache. Second,
the auxiliaries which are available to those regions. Every region and
auxiliary within the cache is identified by a unique ID.
For a region users need to be able to configure
1. The id that identifies the region.
2. The list of auxiliaries that should be used for the region,
possibly with a failover (or sequence of failovers) for each
auxilliary.
3. The memory cache which should be used for the region.
4. A set of cache attributes for the region. Currently the
configuration allows the user to define the class used to
contain the cache attributes, and the set of attributes to
populate it with.
For an auxiliary one needs to be able to configure
1. The id that identifies the auxiliary.
2. The class to use for the auxiliary.
3. The attributes object to use for configuring the auxiliary.
4. The actual attributes.
Two things immediately occur to me. The first is that the specification
of the class to use for attributes seems unnecessary, since there is
exactly one attributes class for each auxiliary, we can simplify
configuration by determining it at runtime. Second, that something like
the mapper might be an easy way to cleanup the configuration using XML.
However the mapper probably doesn't yet offer enough flexibility.
For regions, can the attributes class also be eliminated? In what
situations would one use something other than CompositeCacheAttributes?
I suppose it is configurable to allow more flexibility, but perhaps you
could elaborate on this area Aaron? I noticed the comment in
CacheAttributes says that it should probably be removed. Would it limit
flexibility for the Composite Cache ( Group Cache ? ) to be the only
option? Would seem to simplify things quite a bit conceptually.
> I want to allow the cache to be programmatically configured. Right now,
> if a cache isn't configured in the cache.ccf, it will take the defaults.
> It would be nice if under certain conditions a program that wanted to
> add an auxiliary to a region could do so.
I agree that that would be cool. If we created a standard public
interface for configuring the above things, then one could add regions
or auxiliaries to the cache, and assign auxiliaries to regions at
runtime. This would seem to be a good idea. The configuration mechanism
could use the same interfaces. It would be great if you could read a
configuration file at any time to add new modules to the cache.
> The easiest and cleanest way to do this would be to allow programs to
> get a list of auxiliaries that were in the props file and add or remove
> these from the particular cache region.
Exactly. Really we need to divorce things from the props file at all. At
any given time we have a list of regions and auxiliaries in the cache,
which can be associated. Either programmatic configuration or reading of
another config file can be done at any time to add to those lists, or
add more associations.
> Anything more would be tricky.
I don't know what more people would need, this should allow enough
flexibility.
> I also wouldn't want people to be
> hardcoding configuration in their programs. This is what jcache
> proposes. It is easier for them since they have a fixed set of
> auxiliaries (disk and lateral), but JCS has an array of possibilities
> and they may not play well together. You wouldn't want two disk caches
> and you might have trouble running a remote and a lateral for the same
> region. This shouldn't cause any looping, but the behavior could be
> different. The remote coud be configured to remove upon put and the
> later to put on put. This might get funny and would be wasteful.
Certainly there are bad configurations, but is it worth worrying too
much about preventing users from having two disk caches? This would
probably be better accomplished with documentation and examples. I'm
inclined the best bet is to provide the simplest interface which offers
a nice amount of flexibility.
> One thing that might be nice would be auxiliary failover switching. It
> would be cool to say use this auxiliary and if it goes into an error
> mode, start using this one. An xml config could handle this. The
> current configuration could do this in the list of auxiliaries.
> DC(JISP),RC(LC) -- use the indexed disk cache and iff it fails use the
> JISP. Use the remote cache and if it fails us the lateral cache . . .
> This wouldn't be so hard.
>
> Zombie mode you can detect this and switch. This might involve an
> internal wrapper over the auxiliaries that are added to the cache.
These all seem like good ideas to me as we move forward. I like the idea
of being able to have more flexibility in configuring the cache. While
I'm not sure what the exact nature of the config files should be (I like
XML since there is a bit of hierarchy in the configuration) separating
the configuration of the cache from parsing of the config file, and
making the interfaces for the former public, seems like a good way to
accomplish what we need
Any thoughts?
-- jt
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
