Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 11 Aug 2009, at 16:34, Galder Zamarreno wrote: On 08/10/2009 01:09 PM, Galder Zamarreno wrote: On 08/10/2009 12:42 PM, Manik Surtani wrote: /snip 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 A quick update on this. I have implemented ISPN-152, integrated it with the cache provider and the tests I have are now passing. Just a heads up on a change of behaviour. defineConfiguration(*) methods do no longer throw DuplicateCacheNameException since this limits the API a lot disabling any type of configuration redefininitions/overriding. Example: defineConfiguration(entity, entity, overrides); This means, take the configuration for named cache entity, apply overrides and use that as new entity cache name configuration. If we're throwing DuplicateCacheNameException(s), we wouldn't be able to do this and this seems like a valid use case to me. By the way, I've already noted this in the javadoc but doing the following: Configuration c = defineConfiguration(entity, new Configuration()); is a way to return entity named cache's configuration! (equivalent to doing something like: manager.getConfiguration(entity) if such method existed!) IOW, this defineConfiguration method is saying: define a configuration, based on entity and apply no overrides (cos no setters have been called in the Configuration instance!) and return new configuration instance I've detailed all this in CacheManager's javadoc that you can find attached. If you get the chance, have a read to it and let me know if anything is not clear enough. Most of it sounds good, but the javadoc on defineConfiguration() is a bit misleading. * p/ * If cache name hasn't been defined before, this method creates a clone of the configuration of the cache whose * name matches the given template cache name, then applies the configuration overrides passed and returns this * configuration instance. * p/ * If cache name has been previously defined, this method creates a clone of this cache's existing configuration, * applies the overrides and return this configuration instance. * p/ The first bit makes sense. The second bit though, I would expect the behaviour to be to clone the template cfg, apply changes, and overwrite the existing named config rather than use the existing named config as the template (rather than templateCacheName). Cheers -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/10/2009 01:09 PM, Galder Zamarreno wrote:
On 08/10/2009 12:42 PM, Manik Surtani wrote:
/snip
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
A quick update on this. I have implemented ISPN-152, integrated it with
the cache provider and the tests I have are now passing. Just a heads up
on a change of behaviour.
defineConfiguration(*) methods do no longer throw
DuplicateCacheNameException since this limits the API a lot disabling
any type of configuration redefininitions/overriding. Example:
defineConfiguration(entity, entity, overrides);
This means, take the configuration for named cache entity, apply
overrides and use that as new entity cache name configuration. If
we're throwing DuplicateCacheNameException(s), we wouldn't be able to do
this and this seems like a valid use case to me.
By the way, I've already noted this in the javadoc but doing the following:
Configuration c = defineConfiguration(entity, new Configuration());
is a way to return entity named cache's configuration! (equivalent to
doing something like: manager.getConfiguration(entity) if such method
existed!) IOW, this defineConfiguration method is saying: define a
configuration, based on entity and apply no overrides (cos no setters
have been called in the Configuration instance!) and return new
configuration instance
I've detailed all this in CacheManager's javadoc that you can find
attached. If you get the chance, have a read to it and let me know if
anything is not clear enough.
Cheers
--
Manik Surtani
ma...@jboss.org
Lead, Infinispan
Lead, JBoss Cache
http://www.infinispan.org
http://www.jbosscache.org
--
Galder Zamarreño
Sr. Software Engineer
Infinispan, JBoss Cache
package org.infinispan.manager;
import org.infinispan.Cache;
import org.infinispan.config.Configuration;
import org.infinispan.config.GlobalConfiguration;
import org.infinispan.factories.annotations.NonVolatile;
import org.infinispan.factories.scopes.Scope;
import org.infinispan.factories.scopes.Scopes;
import org.infinispan.lifecycle.ComponentStatus;
import org.infinispan.lifecycle.Lifecycle;
import org.infinispan.notifications.Listenable;
import org.infinispan.remoting.transport.Address;
import java.util.List;
/**
* A ttCacheManager/tt is the primary mechanism for retrieving a {...@link org.infinispan.Cache} instance, and is often
* used as a starting point to using the {...@link org.infinispan.Cache}.
* p/
* ttCacheManager/tts are heavyweight objects, and we foresee no more than one ttCacheManager/tt being used per
* JVM (unless specific configuration requirements require more than one; but either way, this would be a minimal and
* finite number of instances).
* p/
* Constructing a ttCacheManager/tt is done via one of its constructors, which optionally take in a {...@link
* org.infinispan.config.Configuration} or a path or URL to a configuration XML file.
* p/
* Lifecycle - ttCacheManager/tts have a lifecycle (it implements {...@link org.infinispan.lifecycle.Lifecycle}) and
* the default constructors also call {...@link #start()}. Overloaded versions of the constructors are available, that do
* not start the ttCacheManager/tt, although it must be kept in mind that ttCacheManager/tts need to be started
* before they can be used to create ttCache/tt instances.
* p/
* Once constructed, ttCacheManager/tts should be made available to any component that requires a ttCache/tt,
* via a href=http://en.wikipedia.org/wiki/Java_Naming_and_Directory_Interface;JNDI/a or via some other mechanism
* such as an a href=http://en.wikipedia.org/wiki/Dependency_injection;dependency injection/a framework.
* p/
* You obtain ttCache/tt instances from the ttCacheManager/tt by using one of the overloaded
* ttgetCache()/tt, methods. Note that with ttgetCache()/tt, there is no guarantee that the instance you get is
* brand-new and empty, since caches
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 08/11/2009 05:42 PM, Manik Surtani wrote: On 11 Aug 2009, at 16:34, Galder Zamarreno wrote: On 08/10/2009 01:09 PM, Galder Zamarreno wrote: On 08/10/2009 12:42 PM, Manik Surtani wrote: /snip 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 A quick update on this. I have implemented ISPN-152, integrated it with the cache provider and the tests I have are now passing. Just a heads up on a change of behaviour. defineConfiguration(*) methods do no longer throw DuplicateCacheNameException since this limits the API a lot disabling any type of configuration redefininitions/overriding. Example: defineConfiguration(entity, entity, overrides); This means, take the configuration for named cache entity, apply overrides and use that as new entity cache name configuration. If we're throwing DuplicateCacheNameException(s), we wouldn't be able to do this and this seems like a valid use case to me. By the way, I've already noted this in the javadoc but doing the following: Configuration c = defineConfiguration(entity, new Configuration()); is a way to return entity named cache's configuration! (equivalent to doing something like: manager.getConfiguration(entity) if such method existed!) IOW, this defineConfiguration method is saying: define a configuration, based on entity and apply no overrides (cos no setters have been called in the Configuration instance!) and return new configuration instance I've detailed all this in CacheManager's javadoc that you can find attached. If you get the chance, have a read to it and let me know if anything is not clear enough. Most of it sounds good, but the javadoc on defineConfiguration() is a bit misleading. * p/ * If cache name hasn't been defined before, this method creates a clone of the configuration of the cache whose * name matches the given template cache name, then applies the configuration overrides passed and returns this * configuration instance. * p/ * If cache name has been previously defined, this method creates a clone of this cache's existing configuration, * applies the overrides and return this configuration instance. * p/ The first bit makes sense. The second bit though, I would expect the behaviour to be to clone the template cfg, apply changes, and overwrite the existing named config rather than use the existing named config as the template (rather than templateCacheName). Hmmm, right, so defineConfiguration(String, String, Configuration) should work the same way regardless of whether the configuration for the named cache exists or not, correct? In both cases, a clone a clone of the template cache's configuration would be made, apply a clone of the overrides, and overwrite existing named cache's configuration. In fact, a side thing, this has reminded my that then applies the configuration overrides passed should say then applies a clone of the configuration overrides passed in, this makes it clear that the configuration passed in cannot be modified after calling defineConfiguration() and expect its changes to be reflected in the CacheManager. Cheers -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org -- Galder Zamarreño Sr. Software Engineer Infinispan, JBoss Cache ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] [infinispan-dev] [ISPN-6] (Infinispan cache provider for Hibernate) Remaining TODOs, notes and questions
On 11 Aug 2009, at 16:59, Galder Zamarreno wrote: On 08/11/2009 05:42 PM, Manik Surtani wrote: On 11 Aug 2009, at 16:34, Galder Zamarreno wrote: On 08/10/2009 01:09 PM, Galder Zamarreno wrote: On 08/10/2009 12:42 PM, Manik Surtani wrote: /snip 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 A quick update on this. I have implemented ISPN-152, integrated it with the cache provider and the tests I have are now passing. Just a heads up on a change of behaviour. defineConfiguration(*) methods do no longer throw DuplicateCacheNameException since this limits the API a lot disabling any type of configuration redefininitions/overriding. Example: defineConfiguration(entity, entity, overrides); This means, take the configuration for named cache entity, apply overrides and use that as new entity cache name configuration. If we're throwing DuplicateCacheNameException(s), we wouldn't be able to do this and this seems like a valid use case to me. By the way, I've already noted this in the javadoc but doing the following: Configuration c = defineConfiguration(entity, new Configuration()); is a way to return entity named cache's configuration! (equivalent to doing something like: manager.getConfiguration(entity) if such method existed!) IOW, this defineConfiguration method is saying: define a configuration, based on entity and apply no overrides (cos no setters have been called in the Configuration instance!) and return new configuration instance I've detailed all this in CacheManager's javadoc that you can find attached. If you get the chance, have a read to it and let me know if anything is not clear enough. Most of it sounds good, but the javadoc on defineConfiguration() is a bit misleading. * p/ * If cache name hasn't been defined before, this method creates a clone of the configuration of the cache whose * name matches the given template cache name, then applies the configuration overrides passed and returns this * configuration instance. * p/ * If cache name has been previously defined, this method creates a clone of this cache's existing configuration, * applies the overrides and return this configuration instance. * p/ The first bit makes sense. The second bit though, I would expect the behaviour to be to clone the template cfg, apply changes, and overwrite the existing named config rather than use the existing named config as the template (rather than templateCacheName). Hmmm, right, so defineConfiguration(String, String, Configuration) should work the same way regardless of whether the configuration for the named cache exists or not, correct? In both cases, a clone a clone of the template cache's configuration would be made, apply a clone of the overrides, and overwrite existing named cache's configuration. Yup. In fact, a side thing, this has reminded my that then applies the configuration overrides passed should say then applies a clone of the configuration overrides passed in, this makes it clear that the configuration passed in cannot be modified after calling defineConfiguration() and expect its changes to be reflected in the CacheManager. +1. -- Manik Surtani ma...@jboss.org Lead, Infinispan Lead, JBoss Cache http://www.infinispan.org http://www.jbosscache.org ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
