<div dir="ltr">Ales, I don't think the implementation matters that much, I was only concerned about the API. BTW, where could I find some documentation on MSC?<div><br></div><div>Sanne, I missed something in your initial email: you mention a Cache.close() method, did you mean Cache.stop(), or did you mean to add a new close() method?</div>
<div><br></div><div>Cache doesn't actually define a stop() method, it inherits the stop() method from the Lifecycle interface. So changing its semantics only for caches would be hacky. Adding a different close() method would be better, but it still wouldn't be my first choice...<br>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Aug 16, 2014 at 12:40 AM, Ales Justin <span dir="ltr"><<a href="mailto:ales.justin@gmail.com" target="_blank">ales.justin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">What about if you add an SPI for this?<br>
<br>
e.g. this could be nicely implemented on top of WildFly's MSC<br>
<br>
And by default you would keep this simple incRef,<br>
or some similar simple state machine we used in Microcontainer.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Ales<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On 15 Aug 2014, at 16:26, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>> wrote:<br>
<br>
> On 15 August 2014 14:55, Dan Berindei <<a href="mailto:dan.berindei@gmail.com">dan.berindei@gmail.com</a>> wrote:<br>
>> It looks to me like you actually want a partial order between caches on<br>
>> shutdown, so why not declare an explicit dependency (e.g.<br>
>> manager.stopOrder(before, after)? We could even throw an exception if the<br>
>> user tries to stop a cache manually in the wrong order (e.g.<br>
>> TestingUtil.killCacheManagers).<br>
><br>
> Because that's much more complex to implement?<br>
> incRef() seems trivial, effective and can be used by other components<br>
> for different patterns.<br></div></div></blockquote><div><br></div><div>Implementing proper dependencies doesn't need to be difficult either, all we need is to keep a list of dependants in the cache and prune the stopped caches from it before doing the check.<br>
</div><div><br></div><div>incRef might be easier to implement, but instead it seems harder to explain to a user in the Javadoc.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
><br>
>> Alternatively, we could add an event CacheManagerStopEvent(pre=true) at the<br>
>> cache manager level that is invoked before any cache is stopped, and you<br>
>> could close all the indexes in that listener. The event could even be at the<br>
>> cache level, if it would make things easier.<br>
><br>
> I like that more than defining explicit dependency links and it would<br>
> probably be good enough for this specific problem<br>
> but I feel like it doesn't solve similar problems with a more complex<br>
> dependency sequence of services.<br>
> Counters are effectively providing the same semantics, just that you<br>
> can use the pre-close pattern nesting it "count times".<br>
><br>
> Also having ref-counting available makes it easier for users to<br>
> implement independent components - with an independent lifecycle -<br>
> which might share the same cache.<br></div></div></blockquote><div><br></div><div>By independent components do you mean global components? That wouldn't work, since we only start stopping global components after we have stopped all the caches - regardless of the order in which we stop caches. </div>
<div><br></div><div>A global pre-stop event, instead, would allow global components to do stuff before any of the caches is stopped.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
><br>
> -- Sanne<br>
><br>
>><br>
>> Cheers<br>
>> Dan<br>
>><br>
>><br>
>><br>
>> On Fri, Aug 15, 2014 at 3:29 PM, Sanne Grinovero <<a href="mailto:sanne@infinispan.org">sanne@infinispan.org</a>><br>
>> wrote:<br>
>>><br>
>>> The goal being to resolve ISPN-4561, I was thinking to expose a very<br>
>>> simple reference counter in the AdvancedCache API.<br>
>>><br>
>>> As you know the Query module - which triggers on indexed caches - can<br>
>>> use the Infinispan Lucene Directory to store its indexes in a<br>
>>> (different) Cache.<br>
>>> When the CacheManager is stopped, if the index storage caches are<br>
>>> stopped first, then the indexed cache is stopped, this might need to<br>
>>> flush/close some pending state on the index and this results in an<br>
>>> illegal operation as the storate is shut down already.<br>
>>><br>
>>> We could either implement a complex dependency graph, or add a method<br>
>>> like:<br>
>>><br>
>>><br>
>>> boolean incRef();<br>
>>><br>
>>> on AdvancedCache.<br>
>>><br>
>>> when the Cache#close() method is invoked, this will do an internal<br>
>>> decrement, and only when hitting zero it will really close the cache.<br>
>>><br>
>>> A CacheManager shutdown will loop through all caches, and invoke<br>
>>> close() on all of them; the close() method should return something so<br>
>>> that the CacheManager shutdown loop understand if it really did close<br>
>>> all caches or if not, in which case it will loop again through all<br>
>>> caches, and loops until all cache instances are really closed.<br>
>>> The return type of "close()" doesn't necessarily need to be exposed on<br>
>>> public API, it could be an internal only variant.<br>
>>><br>
>>><br>
>>> Could we do this?<br>
>>><br>
>>> --Sanne<br>
>>> _______________________________________________<br>
>>> infinispan-dev mailing list<br>
>>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> infinispan-dev mailing list<br>
>> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
>> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
> _______________________________________________<br>
> infinispan-dev mailing list<br>
> <a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
<br>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</div></div></blockquote></div><br></div></div>