Sorry, last bit of last post got truncated...
"manik.surtani(a)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#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...