On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <sanne(a)infinispan.org>
wrote:
On 20 August 2014 11:19, Dan Berindei <dan.berindei(a)gmail.com>
wrote:
>
>
>
> On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sanne(a)infinispan.org>
> wrote:
>>
>> On 12 August 2014 21:41, Dan Berindei <dan.berindei(a)gmail.com> wrote:
>> >
>> >
>> >
>> > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño
<galder(a)redhat.com>
>> > wrote:
>> >>
>> >> Can’t comment on the document, so here are my thoughts:
>> >>
>> >> Re: “Get rid of lazy cache starting...all the caches run on all
>> >> nodes...it
>> >> should still be possible to start a cache at runtime, but it will be
>> >> run on
>> >> all nodes as well”
>> >>
>> >> ^ Though I like the idea, it might change a crucial aspect of how
>> >> default
>> >> cache configuration works (if we leave the concept of default cache
at
>> >> all).
>> >> Say you start a cache named “a” for which there’s no config. Up until
>> >> now
>> >> we’d use the default cache configuration and create a cache “a” with
>> >> that
>> >> config. However, if caches are started cluster wide now, before you
can
>> >> do
>> >> that, you’d have to check that there’s no cache “a” configuration
>> >> anywhere
>> >> in the cluster. If there is, I guess the configuration would be
shipped
>> >> to
>> >> the node that starts the cache (if it does not have it) and create
the
>> >> cache
>> >> with it? Or are you assuming all nodes in the cluster must have all
>> >> configurations defined?
>> >
>> >
>> > +1 to remove the default cache as a default configuration.
>> >
>> > I like the idea of shipping the cache configuration to all the nodes.
We
>> > will have to require any user-provided objects in the configuration to
>> > be
>> > serializable/externalizable, but I don't see a big problem with that.
>>
>> That would be nice but needs some care, say for example that I want to
>> inject a custom JDBCCacheStore by instance which has a reference to a
>> datasource (Extremely useful use case).
>
>
> Shouldn't the datasource be registered in JNDI anyway? If yes, you could
> serialize the JNDI name.
You don't want to require the user to need to match configuration
settings in different configuration files of what he considers one
platform.
And we support many more options beyond JNDI.
Still, usually we want to share datasources for pooling, so the cache store
should look up its datasource somewhere instead of creating a new
connection pool for each cache.
>> I could make it serializable by changing it from a CacheStore instance
>> to some kind of "CacheStoreLookupStrategy" but you'd need to give
me
>> some hook we can react on to restore the references. Once again (as
>> asked previously) allowing to register custom components by instance
>> in the CacheManager's component Registry would solve this.
>>
>
> We already allow this:
>
>
EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance,
> name)
Can I use that before the CacheManager is started?
Sure, all DefaultCacheManager.start() does is register some MBeans in JMX.
-- Sanne
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev