One approach that may work is to use a ConcurrentMap as a lock container rather than an
array of fixed size. Instead of mapping locks to a modularised hashcode of a given Fqn as
we do now, we could use the Fqn itself as a key to a lock, and use concurrent methods on
the map to locate the lock, creating new ones if absent, etc. It will perform worse (both
in terms of memory and lock locating, since unnecessary locks may be created and thrown
away) but it would prevent the deadlock issue mentioned above.
Also, it would be simple enough to implement as an alternate LockContainer impl and plug
in. Let me give this a bit more thought.
View the original post :
http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4218955#...
Reply to the post :
http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...