I'd suggest to make use of the oswego concurrent library instead of using simple
synchronisation.
e.g. use EDU.oswego.cs.dl.util.concurrent.ConcurrentReaderHashMap instead of
HashMap
this will both:
- enshure we use the 'best-of-breed' solution for concurrent access
- be as close as
I put this on the roadmap
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3848146#3848146
Reply to the post :
http://www.jboss.org/index.html?module=bbop=postingmode=replyp=3848146
---
This SF.Net email is
We cannot let logging introduce errant behavior. If the info required for logging
cannot be obtained in a thread safe manner without undue performance impact, then we
do need to guard against failures due to the unsafe access and catch the exception.
View the original post :
Yes. I'm willing to pay the price for occasional exceptions though in print() methods,
but would not want to synchronize them at all.
Norbert et al: Keep those bug reports coming !
Bela
View the original post :
http://www.jboss.org/index.html?module=bbop=viewtopicp=3847771#3847771
Reply to
my company (10 empl., several hundred instances of J2EE-application-servers) is
planning to use JBoss application-server in production starting 2005. I'll be
technically responsible for this.
From an enterprise customers standpoint anything that is known to fail 'every now and
then' is not
I've notices these kind of exceptions in many areas of jboss-cache's 'toString()'
methods...
It's because all the Collections being used (e.g. ArrayList for readOwnerList in
LockMap.java, HashMap for data in Node.java ... ) are all unsynchronized and throw
ConcurrentModificationException
e.g. in NodeMap it dosn't help that the method readerOwners() is synchronized, but the
Collection (readOwnerList_) being returned by it being unsynchronized.
It wouldn't even help to make the IdentityLock.toString()-method synchronized, since
the JVM's lock on the IdentityLock instance does not
btw:
this is not just an issue of debugging - other methods like the various 'printInfo()'
(even in TreeCache()) eventually throwsConcurrentModificationException when being
called while the cache is in use.
If we want to keep the underlying Collections unsynchronized for performance-reasons,
I think this is a good point. I can see this exception probably doesn't happen that
often with REPEATABLE_READ and up. But with more relaxed isolation levels, it can be a
problem.
Bela and I will be meeting soon. We should visit issue. What do you think, Bela?
-Ben
View the original post :
