So the question is this - with potentially likely events marking a node as invalid - especially with eviction - should we throw a NodeNotValidException? Since (as of 2.1.0), the Node implementation that a user has is an instance of NodeInvocationDelegate which in turn has a reference to an UnversionedNode, perhaps we should handle the NNVE within the NodeInvocationDelegate and perform a lookup internally and refresh the UnversionedNode reference, and THEN throw a NNVE if we can't fetch the node?

Hi All, I have been reading some time but please consider my opinion as a complete newbie. Still I have some experience with concurrency and would like to highlight your attention on the patterns used in the JDK util.concurrency; I use them often and they provide a very clean approach for this sort of problem: the AtomicBoolean (for example) has boolean compareAndSet( boolean expectedValue, boolean newValue) the ConcurrentHashMap has boolean putIfAbsent(Object key, Object value) they all return false if the condition required to set the new value is no longer valid, so I think a clean approach would be to define the Node manipulation API as "boolen setIfValid( ... ) and return false when the Node is no longer valid, so a retry code could be written in clean and readable code. This way you avoid node locking, and also you have fail-fast: if I had to mark a node as "do not evict" it means I'm doing some useless work, as far as I have understood it the result will be thrown to garbage as soon as we finished working on the Node, I think it would be preferrable to avoid the work at all or write it to the most current Node. (please just let me know if I wrote stupid things, as I said I still don't know the internal wroking of the cache) regards, Sanne Grinovero 2008/5/16 Elias Ross <genman(a)noderunner.net&gt;: > On Thu, May 15, 2008 at 3:52 PM, Manik Surtani <manik(a)jboss.org&gt; > wrote: > >> So the question is this - with potentially likely events marking a >> node as >> invalid - especially with eviction - should we throw a >> NodeNotValidException? Since (as of 2.1.0), the Node >> implementation that a >> user has is an instance of NodeInvocationDelegate which in turn >> has a >> reference to an UnversionedNode, perhaps we should handle the NNVE >> within >> the NodeInvocationDelegate and perform a lookup internally and >> refresh the >> UnversionedNode reference, and THEN throw a NNVE if we can't fetch >> the node? > > Something feels wrong about using exceptions as message passing > events > and flow control. > > You should be able to check if a node is invalid before that > exception > gets thrown. And if you do a retry, it seems possible to get stuck in > a loop: Exception, refresh succeeds, but immediate eviction again, > then exception again, etc. Maybe it's really unlikely, but it'd be a > bummer. > > Wouldn't an evict require a write lock? If so, then this couldn't > happen. > > Or do this as part of the interception: > 1. Pre-fetch node, mark as "do not evict", then check again if node > is > valid (would have to use a volatile flag I think) > 2. Do your business > 3. Unmark > _______________________________________________ > jbosscache-dev mailing list > jbosscache-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/jbosscache-dev >

Guys, I've been thinking about behaviour with the Node API, and wonder what works best from a user standpoint. Consider: * User gets a hold of a node and holds on to the ref for performance reasons (Node n = cache.getNode(fqn)) * Performs tasks on the node: n.put(), n.get(), etc. * Node checks for validity before performing any API calls, throwing a NodeNotValidException if the node is not valid anymore. Nodes get marked as invalid if they are removed or moved by a concurrent thread, or invalidated by a remote one. Eviction did not mark a node as invalid, but I think this is inconsistent and a bug: eviction too should mark the node as invalid. So the question is this - with potentially likely events marking a node as invalid - especially with eviction - should we throw a NodeNotValidException? Since (as of 2.1.0), the Node implementation that a user has is an instance of NodeInvocationDelegate which in turn has a reference to an UnversionedNode, perhaps we should handle the NNVE within the NodeInvocationDelegate and perform a lookup internally and refresh the UnversionedNode reference, and THEN throw a NNVE if we can't fetch the node? Th drawback is that this is potentially two calls for what should be one - node gets evicted, we call cache.getNode() internally to refresh the reference (from a cache loader, etc), and then invoke whatever call the user intended to call up the interceptor chain. The benefit is a smoother user experience. Thoughts/opinions? Cheers, -- Manik Surtani Lead, JBoss Cache manik(a)jboss.org _______________________________________________ jbosscache-dev mailing list jbosscache-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/jbosscache-dev