[infinispan-dev] Caches need be stopped in a specific order to respect cross-cache dependencies

[Dan Berindei]

It looks to me like you actually want a partial order between caches on
shutdown, so why not declare an explicit dependency (e.g.
manager.stopOrder(before, after)? We could even throw an exception if the
user tries to stop a cache manually in the wrong order (e.g.
TestingUtil.killCacheManagers).

Alternatively, we could add an event CacheManagerStopEvent(pre=true) at the
cache manager level that is invoked before any cache is stopped, and you
could close all the indexes in that listener. The event could even be at
the cache level, if it would make things easier.

Cheers
Dan



On Fri, Aug 15, 2014 at 3:29 PM, Sanne Grinovero <sanne at infinispan.org>
wrote:

> The goal being to resolve ISPN-4561, I was thinking to expose a very
> simple reference counter in the AdvancedCache API.
>
> As you know the Query module - which triggers on indexed caches - can
> use the Infinispan Lucene Directory to store its indexes in a
> (different) Cache.
> When the CacheManager is stopped, if the index storage caches are
> stopped first, then the indexed cache is stopped, this might need to
> flush/close some pending state on the index and this results in an
> illegal operation as the storate is shut down already.
>
> We could either implement a complex dependency graph, or add a method like:
>
>
>   boolean incRef();
>
> on AdvancedCache.
>
> when the Cache#close() method is invoked, this will do an internal
> decrement, and only when hitting zero it will really close the cache.
>
> A CacheManager shutdown will loop through all caches, and invoke
> close() on all of them; the close() method should return something so
> that the CacheManager shutdown loop understand if it really did close
> all caches or if not, in which case it will loop again through all
> caches, and loops until all cache instances are really closed.
> The return type of "close()" doesn't necessarily need to be exposed on
> public API, it could be an internal only variant.


> Could we do this?
>
> --Sanne
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20140815/5b529916/attachment.html