<div dir="ltr"><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 2:32 PM, Sanne Grinovero <span dir="ltr">&lt;<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>&gt;</span> wrote:<br>


<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 20 August 2014 11:19, Dan Berindei &lt;<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>&gt; wrote:<br>



&gt;<br>
&gt;<br>
&gt;<br>
&gt; On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero &lt;<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>&gt;<br>
&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; On 12 August 2014 21:41, Dan Berindei &lt;<a href="mailto:dan.berindei@gmail.com" target="_blank">dan.berindei@gmail.com</a>&gt; wrote:<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño &lt;<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</a>&gt;<br>
&gt;&gt; &gt; wrote:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Can’t comment on the document, so here are my thoughts:<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; Re: “Get rid of lazy cache starting...all the caches run on all<br>
&gt;&gt; &gt;&gt; nodes...it<br>
&gt;&gt; &gt;&gt; should still be possible to start a cache at runtime, but it will be<br>
&gt;&gt; &gt;&gt; run on<br>
&gt;&gt; &gt;&gt; all nodes as well”<br>
&gt;&gt; &gt;&gt;<br>
&gt;&gt; &gt;&gt; ^ Though I like the idea, it might change a crucial aspect of how<br>
&gt;&gt; &gt;&gt; default<br>
&gt;&gt; &gt;&gt; cache configuration works (if we leave the concept of default cache at<br>
&gt;&gt; &gt;&gt; all).<br>
&gt;&gt; &gt;&gt; Say you start a cache named “a” for which there’s no config. Up until<br>
&gt;&gt; &gt;&gt; now<br>
&gt;&gt; &gt;&gt; we’d use the default cache configuration and create a cache “a” with<br>
&gt;&gt; &gt;&gt; that<br>
&gt;&gt; &gt;&gt; config. However, if caches are started cluster wide now, before you can<br>
&gt;&gt; &gt;&gt; do<br>
&gt;&gt; &gt;&gt; that, you’d have to check that there’s no cache “a” configuration<br>
&gt;&gt; &gt;&gt; anywhere<br>
&gt;&gt; &gt;&gt; in the cluster. If there is, I guess the configuration would be shipped<br>
&gt;&gt; &gt;&gt; to<br>
&gt;&gt; &gt;&gt; the node that starts the cache (if it does not have it) and create the<br>
&gt;&gt; &gt;&gt; cache<br>
&gt;&gt; &gt;&gt; with it? Or are you assuming all nodes in the cluster must have all<br>
&gt;&gt; &gt;&gt; configurations defined?<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; +1 to remove the default cache as a default configuration.<br>
&gt;&gt; &gt;<br>
&gt;&gt; &gt; I like the idea of shipping the cache configuration to all the nodes. We<br>
&gt;&gt; &gt; will have to require any user-provided objects in the configuration to<br>
&gt;&gt; &gt; be<br>
&gt;&gt; &gt; serializable/externalizable, but I don&#39;t see a big problem with that.<br>
&gt;&gt;<br>
&gt;&gt; That would be nice but needs some care, say for example that I want to<br>
&gt;&gt; inject a custom JDBCCacheStore by instance which has a reference to a<br>
&gt;&gt; datasource (Extremely useful use case).<br>
&gt;<br>
&gt;<br>
&gt; Shouldn&#39;t the datasource be registered in JNDI anyway? If yes, you could<br>
&gt; serialize the JNDI name.<br>
<br>
</div></div>You don&#39;t want to require the user to need to match configuration<br>
settings in different configuration files of what he considers one<br>
platform.<br>
And we support many more options beyond JNDI.<br>
<div><br></div></blockquote><div><br></div><div>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.</div>


<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
<br>
&gt;&gt; I could make it serializable by changing it from a CacheStore instance<br>
&gt;&gt; to some kind of &quot;CacheStoreLookupStrategy&quot; but you&#39;d need to give me<br>
&gt;&gt; some hook we can react on to restore the references. Once again (as<br>
&gt;&gt; asked previously) allowing to register custom components by instance<br>
&gt;&gt; in the CacheManager&#39;s component Registry would solve this.<br>
&gt;&gt;<br>
&gt;<br>
&gt; We already allow this:<br>
&gt;<br>
&gt; EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance,<br>
&gt; name)<br>
<br>
</div>Can I use that before the CacheManager is started?<br></blockquote><div><br></div><div>Sure, all DefaultCacheManager.start() does is register some MBeans in JMX.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<span><font color="#888888"><br>
-- Sanne<br>
</font></span><div><div><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org" target="_blank">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></div></div></blockquote></div><br></div></div>