[infinispan-dev] cache loader: purgerThreads and purgeSynchronously

Mircea Markus mmarkus at redhat.com
Wed Aug 14 12:49:30 EDT 2013


On 14 Aug 2013, at 17:39, Sanne Grinovero <sanne at infinispan.org> wrote:

> On 14 August 2013 15:39, Manik Surtani <msurtani at redhat.com> wrote:
>> I agree with you, Sanne.
> 
> +1 always good :P
> 
>> But I think from a config perspective, this does need an overhaul.
> 
> +1
> 
>> I think the correct approach - given some of the newly forming ideas on the CacheLoader/CacheStore SPI we've been having - is to not specify whether purging is synchronous or not
> 
> +1 that is implementation specific, some might even not need a purger
> at all as - for example - a remote Infinispan store does understand
> how to cleanup by itself.
> 
>> and not to specify a number of threads, but instead to point to a named executor.
>> E.g., the way we define executors for async notification, async transport, etc.
> 
> +1 sounds good and consistent, but let's improve even more on consistency:
> 
> If we're reorganizing the CacheLoader configuration schema,

the focus is no the configuration Sanne, but getting rid(revisiting) the elements that don't make sense anymore.

> I would
> very much like it to finally have named CacheStore/Loader elements
> like we do with Executors, and being able to refer to them from Caches
> rather than nesting their configuration in a Cache element.
> If you ever configured - for example - a JDBCCacheStore for at least 3
> caches in the same CacheManager, you know how much this is desirable.
> 
> Mircea: we've spoken about that option several times, AFAIR your main
> point to not do that (yet) was to not introduce changes in the
> configuration schema.

That was not the reason for not doing it now :-)
6.0 is very busy as it is and I don't want to add new stuff unless is critical.
We plan to revamp the XML configuration in 7.0, let's do this at that point.

> Since it seems you're restructuring it all,
> let's do it all :-)



Cheers,
-- 
Mircea Markus
Infinispan lead (www.infinispan.org)







More information about the infinispan-dev mailing list