[infinispan-dev] Starting caches in parallel

[Pete Muir]

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