Re: [jbosscache-dev] API changes in Habanero

On 5 Jan 2007, at 01:39, Ben Wang wrote: Not really for cache behaviour customisation at all, but for direct node access. E.g., Node.get(Object key) could do 2 things: 1) pass a call up the interceptor stack, to make sure the node is locked, cache loaders are considered, etc etc, and then retrieve the value of some data in the node. 2) or it could ignore the interceptor stack and retrieve some data from the node's data map. In JBC 1.x, (1) was never supported directly from a node. You had to go through TreeCache to do this. Node.get() always performed (2). in 2.0.0.ALPHA1, both (1) and (2) were supported, depending on whether BypassInterceptorChain was set to true as an option. I explained earlier how this is ugly, cumbersome, and not performant (constant checking of a thread-local variable) This is why for 2.0.0.ALPHA2, I split such methods into 2 separate ones. Node.get(Object key) performs (1) above. NodeSPI.getDirect (Object fqn) performs (2) above. This also nicely encapsulates direct access from the user API. I'm not sure what you meant by explicit naming, I thought this is what I have achieved here. :-) Previously naming was ambiguous in that the method performed one of two things - (1) or (2) above - based on an option passed in. Really bad design to rely on a 'global' like that. :-) Yes, I put this in since I was trying to emulate direct child access for the node in the xxxDirect() methods. But you are correct, I don't see why this has to be the case and I have changed it in CVS HEAD to not throw this exception and walk the tree internally. I also need to update the javadocs on the xxxDirect() methods to state that the onus is on the caller to make sure appropriate locks are obtained, etc. as this call does not go through the interceptor chain. Given that the intent of these methods are for SPI use only, typically from within an interceptor, the user of the SPI would be aware of such constraints and be able to deal with it. And as a tangent, I was thinking about checking on access for such direct methods and wanted everyone's ideas: At the moment, xxxDirect() methods that access, for example, the child map or data map of a node are synchronized. Now this is overkill, but it enforces correctness. Since we assume that callers to the xxxDirect() methods obtain appropriate locks in all cases, is it safe to remove the synchronization, and instead add a lock- ownership check to such methods. For example: public Object getDirect(Object key) { if (!getLock().getReaderOwners().contains(Thread.currentThread())) throw new CacheException("Current thread does not have a read lock on node " + fqn); return data == null? null : data.get(key); } This would pretty rightly encapsulate and enforce concurrent access rules on the nodes, even with direct access. And cheaper than synchronizing the direct access methods. What do you guys think? Cheers, Manik