[infinispan-dev] Starting caches in parallel

[Sanne Grinovero]

2011/8/4 Dan Berindei <dan.berindei at gmail.com>:
> Hi guys
>
> I've found a deadlock with transactions spanning multiple caches
> during rehashing if the joiner's caches are started sequentially (for
> more details see https://gist.github.com/1124740)
> After discussing a bit on IRC with Manik and Galderz it appears the
> only solution for 5.0.0.FINAL would be to have a mechanism to start
> all the caches in parallel.
>
> There are several options to implement that. All of them require the
> users to know that they should create the caches in parallel at
> application startup to avoid problems.
>
> 1. Advise the users about the problem, but let them create their own
> threads and call EmbeddedCacheManager.getCache() on those threads.
>
>
> 2. Add a method EmbeddedCacheManager.getCaches() to start multiple
> caches in parallel.
>
> This is not as straightforward as it may seem, first there is a
> question of whether to use template parameters or not:
> 2.a. Set<Cache> getCaches(String... cacheNames);
> vs
> 2.b. Set<Cache<K, V>> getCaches(String... cacheNames);
>
> I don't think having the same K and V for all the caches is going to
> be very common, so I'd go with 2.a.
>
> Then there is the problem of how to request the default cache. I think
> "" should be fine, but we'd need to document it and also change the
> regular getCache() methods to accept it.

You could use org.infinispan.manager.CacheContainer.DEFAULT_CACHE_NAME.

> 3. Add an async version of EmbeddedCacheManager.getCache():
>
> Future<Cache<K, V>> getCacheAsync(String cacheName);
> Future<Cache<K, V>> getCacheAsync();
>
> This nicely sidesteps the generics issue in solution 2 and it's also
> easier for the users than solution 1, so it's currently my favourite.
>
>
> What do you think?

I think it's very bad but it doesn't surprise me, since starting more
than a single cache in sequence brings you in the scenario of
ISPN-658,
unless you're quick enough. So yes it's not nice, but we highlighted
the problem since long I think?

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.

Cheers,
Sanne