On 20 August 2014 16:36, Dan Berindei <dan.berin...@gmail.com> wrote: > > > On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <sa...@infinispan.org> > wrote: >> >> On 20 August 2014 11:19, Dan Berindei <dan.berin...@gmail.com> wrote: >> > >> > >> > >> > On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <sa...@infinispan.org> >> > wrote: >> >> >> >> On 12 August 2014 21:41, Dan Berindei <dan.berin...@gmail.com> wrote: >> >> > >> >> > >> >> > >> >> > On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <gal...@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.
Yes that's exactly my point: I want to be able to share a pool I already have with a CacheManager instance I'm creating. >> >> 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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/infinispan-dev > > > > _______________________________________________ > infinispan-dev mailing list > infinispan-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/infinispan-dev _______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
