[infinispan-dev] [hibernate-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions

[Galder Zamarreno]

On 08/10/2009 12:42 PM, Manik Surtani wrote:
>
> 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.

https://jira.jboss.org/jira/browse/ISPN-151

>
>>
>>>
>>> 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?

That would be a great way to combine the two API requirements. I assume 
that the returned Configuration instances returned would have had the 
overrides applied to them already.

Let me work on this APIs in parallel to the work I'm doing for ISPN-6 so 
that I can fully exercise/test and see if there's anything we'd need to 
change.

https://jira.jboss.org/jira/browse/ISPN-152

>
> Cheers
> --
> Manik Surtani
> manik at jboss.org
> Lead, Infinispan
> Lead, JBoss Cache
> http://www.infinispan.org
> http://www.jbosscache.org
>
>
>
>

-- 
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache