On 8 Aug 2009, at 08:14, Galder Zamarreno wrote:
On 08/07/2009 02:06 PM, Manik Surtani wrote:
>
> On 7 Aug 2009, at 12:51, Galder Zamarreno wrote:
>
>> Manik,
>>
>> While I working on this, I've noted the following. If we define
>> default cache configurations for entity/query/...etc in an
>> infinispan
>> configuration file, currently, they cannot be overriden afterwards
>> programatically.
>>
>> IOW, imagine there's a cache named "entity" that applies to all
>> entities in a sample infinispan-configs.xml and then someone
>> tweaks it
>> in the hibernate config like this:
>>
>> hibernate.cache.infinispan.entity.eviction.wake_up_interval=3000
>>
>> The way I'd deal with this is that I'd create a Configuration with
>> this new interval and call defineCache("entity", cfg). However, when
>> the configuration file was processed, "entity" cache was added to
>> the
>> configuration overrides and hence when I call defineCache with
>> "entity", it throws DuplicateCacheNameException.
>>
>> So, I think DFC.initialize() shouldn't add such configurations to
>> configuration overridesm map.
>>
>> Thoughts?
>
> Hmm. Perhaps what is needed is a mechanism to retrieve these
> configurations and alter them. E.g.,
>
> CacheManager.getConfiguration(); // retrieves the default cfg
> CacheManager.getConfiguration(String name);
Yeah, without starting the cache! Right now, the only way to get a
configuration is after doing manager.getCache() which effectively
starts the cache and hence, the Configuration's ComponentRegistry is
in RUNNING mode, so you can't just clone it and modify it to be used
somewhere else. Even the clone is in running state and didn't find
an easy way to change that.
There's a second possibility here too: My above suggestion won't
just work cos what defineCache("entity", cfg) does is take the
*default* cache configuration, apply the overrides and create one
with name "entity". But I want to do is: take the "entity" named
cache configuration, apply the overrides and create a brand new one
with the same name "entity". So, a method like this:
defineCache(String cacheName, String baseNamedCache, Configuration
overrides).
That would work as well. Javadocs need to be clear though as to what
is cloned and ready for use, etc.
So, then apart from doing defineCache("entity", "entity",
overrides), I could also do defineCache("com.acme.Person", "entity",
overrides). The latter would define a cache for com.acme.Person
entity type, based on "entity" named cache and applying overrides
defined via hibernate.cfg.xml
>
> These Configuration objects - built based on what's in the XML file -
> can then be tweaked. These should be adequately javadoc'd to make it
> clear that caches already started using such a configuration will
> not be
> affected when a configuration changes.
Indeed, getConfiguration() would return clones who's running state
has been cleared. Maybe Configuration.clone() should already be
doing that?
This should be true as well. The state should never be cloned.
>
> I guess this also renders CacheManager.defineCache() API
> useless/obsolete, since getConfiguration() should always return a
> configuration, even if one didn't exist /wasn't defined in XML.
Yeah, it's either enhanced defineCache() or getConfiguration(). I
think CacheManager.getConfiguration() is likely to be a more
powerful and simpler API than defineCache(*).
Well, I think we need both.
getConfiguration(String name) to retrieve a configuration template and
modify it.
defineCache(String newName, String templateName, Configuration
overrides) to create a new configuration based on an existing one.
Maybe this name should change to something more intuitive? Perhaps
instead of defineCache, we have:
Configuration defineConfiguration(String configurationName,
Configuration overrides) // registers and names a NEW configuration,
based on the default cfg and the overrides passed in
Configuration defineConfiguration(String configurationName, String
templateName, Configuration overrides) // registers and names a NEW
configuration, based on an existing, predefined configuration and the
overrides passed in
WDYT?
Cheers
--
Manik Surtani
manik(a)jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org