[jboss-dev-forums] [Design of JBossCache] - Re: API Issues integrating 2.0.0.DR1 in HEAD

[bstansberry@jboss.com]

Sorry, last bit of last post got truncated... 

"manik.surtani at jboss.com" wrote : anonymous wrote : 
  |   | 6) The Node interface desribes various returned Collections as being immutable. From a glance at NodeImpl it looks like they aren't. Also, it would be good to be more clear about thread safety as immutable and thread safe aren't the same.
  |   | 
  | 
  | Which ones aren't?  I may have missed some.  The point is not for thread safety, but so changes go through the Node or Cache API and hence the interceptor stack.
  | 

Never mind re: not being immutable.  I was looking at NodeImpl, which I see now doesn't actually implement Node. :-)

The concern I have re: thread safety is if a collection backed by the internal data structure of a node is exposed, you can get a ConcurrentModificationException just iterating over it.  Not sure if that really happens.  I saw NodeImpl.getDataKeys() exposes a collection backed by the data map.  Haven't followed the code to see what happens to it.  But, if that gets passed to a caller, any lock on the node could easily be released before the collection is even received by the caller (assume no tx).  Thus easy to have another thread modify the data map via a put/remove  while the first thread is iterating.  Actually, as I write this, if what I'm describing is there, it's not a javadoc issue, it's something that needs to be changed.

View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3978959#3978959

Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=3978959