<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Aug 20, 2014 at 1:08 PM, Sanne Grinovero <span dir="ltr"><<a href="mailto:sanne@infinispan.org" target="_blank">sanne@infinispan.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="">On 12 August 2014 21:41, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Tue, Aug 5, 2014 at 11:27 AM, Galder Zamarreño <<a href="mailto:galder@redhat.com">galder@redhat.com</a>> wrote:<br>
>><br>
>> Can’t comment on the document, so here are my thoughts:<br>
>><br>
>> Re: “Get rid of lazy cache starting...all the caches run on all nodes...it<br>
>> should still be possible to start a cache at runtime, but it will be run on<br>
>> all nodes as well”<br>
>><br>
>> ^ Though I like the idea, it might change a crucial aspect of how default<br>
>> cache configuration works (if we leave the concept of default cache at all).<br>
>> Say you start a cache named “a” for which there’s no config. Up until now<br>
>> we’d use the default cache configuration and create a cache “a” with that<br>
>> config. However, if caches are started cluster wide now, before you can do<br>
>> that, you’d have to check that there’s no cache “a” configuration anywhere<br>
>> in the cluster. If there is, I guess the configuration would be shipped to<br>
>> the node that starts the cache (if it does not have it) and create the cache<br>
>> with it? Or are you assuming all nodes in the cluster must have all<br>
>> configurations defined?<br>
><br>
><br>
> +1 to remove the default cache as a default configuration.<br>
><br>
> I like the idea of shipping the cache configuration to all the nodes. We<br>
> will have to require any user-provided objects in the configuration to be<br>
> serializable/externalizable, but I don't see a big problem with that.<br>
<br>
</div>That would be nice but needs some care, say for example that I want to<br>
inject a custom JDBCCacheStore by instance which has a reference to a<br>
datasource (Extremely useful use case).<br></blockquote><div><br></div><div>Shouldn't the datasource be registered in JNDI anyway? If yes, you could serialize the JNDI name.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
I could make it serializable by changing it from a CacheStore instance<br>
to some kind of "CacheStoreLookupStrategy" but you'd need to give me<br>
some hook we can react on to restore the references. Once again (as<br>
asked previously) allowing to register custom components by instance<br>
in the CacheManager's component Registry would solve this.<br>
<br></blockquote><div><br></div><div>We already allow this:</div><div><br></div><div><div>EmbeddedCacheManager.getGlobalComponentRegistry().registerComponent(instance, name)</div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Cheers<br>
<div class=""><div class="h5"><br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">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>