&quot;manik.surtani(a)jboss.com&quot; wrote : | "genman" wrote : | | 4. Some of the NodeSPI data methods appear to be just convenience methods and aren't strictly necessary given that getDataDirect() returns an externally modifiable map. For instance, clearDataDirect() really just is the same as NodeSPI.getDataDirect().clear(). So, it would be nice to understand the reason for these extra methods. | | This is a good point. Will revisit thise. Their Node interface counterparts that went up the interceptor stack made sense, but the 'direct' versions do not. Actually, there is a good reason to still maintain these methods. At some point I plan to do away with synchronizing these methods, and have my own lock checks to ensure the caller has appropriate locks. And to do this, I need to make sure the Map returned to getDataDirect() is an unmodifiableMap. In fact, all read calls would return unmodifiableMap/Sets, and the only way to write in to them would be to use the write methods. Read and Write methods would then impose a check on the caller to see if appropriate locks are available, e.g., | pubic Map<Object, Object> getDataDirect() | { | if (!getLock().getReaderOwners().contains(Thread.currentThread())) | throw new LockingException(); | | // defensive copy + unmodifiable | return Collections.unmodifiableMap(new HashMap(data)); | } | View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3999722#... Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...