On 14 Aug 2013, at 15:26, Sanne Grinovero <sanne(a)infinispan.org> wrote:
On 14 August 2013 11:15, Mircea Markus <mmarkus(a)redhat.com>
wrote:
> Currently the "preload" attribute is configured at *loaders* level and the
first cache loader in the chain is used for preloading.
> 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.
>
> How does it sound?
Very confusing actually :-)
Are you going to prevent me to enable "preload" on multiple Cache
Loaders elements?
I'm not going to take anything from you, this is something you're not allowed to
do ATM :-)
And what if I'm actually storing entries in
different CacheStore instanced based on some discriminator, like the
value (key) type?
To make a practical example, the Lucene Directory CacheLoader only
loads some specific types, and only from named indexes which match a
configured name. You could want multiple instances using different
configurations, so that for each index name stored in the same cache
you actually store them in different cachestores.
Similar situation, with the JPA CacheStore you might want to use
multiple independent instances, one per mapped type. Not necessarily
needed (one could improve the CacheStore implementation as well) but
it gives lot of flexibility, like connecting to different RDBMs
instances or with different credentials/schemas, etc...
Indeed user might want this in the future. Moving "preload" at
"loader" level would only facilitate that.
Cheers,
Sanne
>
> Cheers,
> --
> Mircea Markus
> Infinispan lead (
www.infinispan.org)
>
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/infinispan-dev
_______________________________________________
infinispan-dev mailing list
infinispan-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/infinispan-dev
Cheers,
--
Mircea Markus
Infinispan lead (
www.infinispan.org)