[infinispan-dev] Starting caches in parallel

Pete Muir pmuir at redhat.com
Thu Aug 4 10:13:47 EDT 2011


On 4 Aug 2011, at 15:12, Galder Zamarreño wrote:

> 
> On Aug 4, 2011, at 3:43 PM, Pete Muir wrote:
> 
>> 
>> On 4 Aug 2011, at 14:01, Galder Zamarreño wrote:
>> 
>>> 
>>> On Aug 4, 2011, at 1:01 PM, Sanne Grinovero wrote:
>>> 
>>>> 2011/8/4 Dan Berindei <dan.berindei at gmail.com>:
>>>>> </snip>
>>>> 
>>>> Are you proposing a temporary API to make things work before ISPN-658
>>>> is solved? I don't like the Future approach, it's still unclear that I
>>>> have to send all requests before blocking on any get.
>>>> I'd make a
>>>> 
>>>> void startCaches(String... names);
>>>> 
>>>> which implicitly includes the default cache too, and you throw an
>>>> exception if getCache() is used on an unstarted cache, and
>>>> unfortunately you should also throw an exception if startCaches() is
>>>> invoked more than once.
>>> 
>>> We talk about this option too as indicated in https://gist.github.com/1124740, but I personally don't like it at this stage, since that'd be changing the programming model. People are expecting start caches with getCache(). It's been like that since 4.0 so what you're suggesting would be a bit change at this stage (5.0.0.CR8) IMO. Your suggestion would be worth considering for 6.x.
>> 
>> Dan's latest email contains an updated proposal, which would mean that getCache would still start the cache for 5.0 (and possibly 5.x) but would be "deprecated" (not recommended by docs, javadocs updated, warning logged) if called on an unstarted cache. startCaches would also be available in 5.x for those who do need to start multiple caches.
>> 
>> WDYT? It seems to me this:
>> 
>> * improves the API (makes the behavior of getCache more expected - just a getter, and completely idempotent)
>> * indicates to the user that they do need to start the cache, and probably they will be more likely to start the cache at app start as well
>> * doesn't break the existing API, but does offer a way to get around the problem
> 
> Ok, let's go with this as long as the old method is left around. startCaches would definitely make the API cleaner.
> 
> Btw, let's make the API fluent, so instead of:

Nice :-)

> 
> void startCaches(String... names);
> 
> Do:
> 
> CacheContainer startCaches(String... names);
> 
> To be able to do:
> 
> startCaches(x).getCache(x)
> 
> But we can't go final directly after making this change. We need at least another CR to fix any potential issues that might require changing the API.
> 
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
> 
> --
> Galder Zamarreño
> Sr. Software Engineer
> Infinispan, JBoss Cache
> 
> 
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev




More information about the infinispan-dev mailing list