<div dir="ltr"><br><div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 16, 2013 at 5:05 AM, Galder Zamarreño <span dir="ltr"><<a href="mailto:galder@redhat.com" target="_blank">galder@redhat.com</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="im"><br>
On Aug 15, 2013, at 4:25 AM, Ray Tsang <<a href="mailto:saturnism@gmail.com">saturnism@gmail.com</a>> wrote:<br>
<br>
> Btw how do we deal with preloading in a cluster?<br>
<br>
</div>Each node preloads locally only.<br></blockquote><div><br></div><div style>How is this done? Is it through loadAllKeys first, and then determining which keys are local?</div><div style>Or do you mean it preloads locally from a non-shared cache store? What if the cache store is shared?</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">
<div class="im"><br>
> Eg how do we prevent every node from preloading the same data?<br>
<br>
</div>Preloaded data is not replicated/distributed to other nodes, in order to speed up process. For replicated caches, each node loads its own stuff (from local or shared). For distributed caches, I don't think we're intelligent enough to only load data that belongs to a particular node (I think there's some jiras on this topic…)<br>
</blockquote><div><br></div><div style>For replicated cache, when it loads the data, does it put to the local cache container only? (i.e., avoid unnecessarily replicating to other nodes of course).</div><div style><br></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">
<br>
Cheers,<br>
<div class=""><div class="h5"><br>
><br>
> On Aug 14, 2013, at 16:09, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
><br>
>><br>
>> On 14 Aug 2013, at 20:53, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
>><br>
>>> On 14 August 2013 17:59, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>>>><br>
>>>> On 14 Aug 2013, at 15:26, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
>>>><br>
>>>>> On 14 August 2013 11:15, Mircea Markus <<a href="mailto:mmarkus@redhat.com">mmarkus@redhat.com</a>> wrote:<br>
>>>>>> Currently the "preload" attribute is configured at *loaders* level and the first cache loader in the chain is used for preloading.<br>
>>>>>> A better place for preload might be the individual loader element: would indicate clearly which loader is used for preloading and also consistent with the fetchPeristentState which is again defined on a per loader basis.<br>
>>>>>><br>
>>>>>> How does it sound?<br>
>>>>><br>
>>>>> Very confusing actually :-)<br>
>>>>> Are you going to prevent me to enable "preload" on multiple Cache<br>
>>>>> Loaders elements?<br>
>>>><br>
>>>> I'm not going to take anything from you, this is something you're not allowed to do ATM :-)<br>
>>><br>
>>> That's exactly my point. I'm not allowed to do it ATM, but if you<br>
>>> change the position of this attribute to *each* loader it will look<br>
>>> like I could enable/disable it differently on a per-instance.<br>
>><br>
>> Gotcha, I'll either add a check to allow specifying preload on a single store, or (if time allows) I'll implement the multiple preload feature.<br>
>><br>
>>><br>
>>>><br>
>>>>> And what if I'm actually storing entries in<br>
>>>>> different CacheStore instanced based on some discriminator, like the<br>
>>>>> value (key) type?<br>
>>>>><br>
>>>>> To make a practical example, the Lucene Directory CacheLoader only<br>
>>>>> loads some specific types, and only from named indexes which match a<br>
>>>>> configured name. You could want multiple instances using different<br>
>>>>> configurations, so that for each index name stored in the same cache<br>
>>>>> you actually store them in different cachestores.<br>
>>>>><br>
>>>>> Similar situation, with the JPA CacheStore you might want to use<br>
>>>>> multiple independent instances, one per mapped type. Not necessarily<br>
>>>>> needed (one could improve the CacheStore implementation as well) but<br>
>>>>> it gives lot of flexibility, like connecting to different RDBMs<br>
>>>>> instances or with different credentials/schemas, etc...<br>
>>>><br>
>>>> Indeed user might want this in the future. Moving "preload" at "loader" level would only facilitate that.<br>
>>><br>
>>> Right. I'm making those examples to highlight the benefit of moving<br>
>>> the attribute to each cachestore, as you proposed, but this only makes<br>
>>> sense if you actually allow the option to be applied differently for<br>
>>> each instance.<br>
>><br>
>> Cheers,<br>
>> --<br>
>> Mircea Markus<br>
>> Infinispan lead (<a href="http://www.infinispan.org" target="_blank">www.infinispan.org</a>)<br>
>><br>
>><br>
>><br>
>><br>
>><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><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><br>
<br>
<br>
</div></div><div class="im">--<br>
Galder Zamarreño<br>
<a href="mailto:galder@redhat.com">galder@redhat.com</a><br>
<a href="http://twitter.com/galderz" target="_blank">twitter.com/galderz</a><br>
<br>
Project Lead, Escalante<br>
<a href="http://escalante.io" target="_blank">http://escalante.io</a><br>
<br>
Engineer, Infinispan<br>
<a href="http://infinispan.org" target="_blank">http://infinispan.org</a><br>
<br>
<br>
</div><div class=""><div class="h5">_______________________________________________<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><br>
</div></div></blockquote></div><br></div></div></div>