To clarify two things:
1) In my app, running on some dual processors Xeons w/ Hyperthreading contention on this
lock starts to show up with maybe... w/ 20 concurrent .seam connections. Below that
there is no locking on it.
But above that most of the threads are waiting on this lock.
(The section in the actual synchronized method in Class is basically just a null check.
So it looks like just acquiring the lock (and the memory implications of that ) that are
causing problems not the stuff that's going on in the synchronized method.)
2) If there is no strong objection i'd like this change made in the core code so that
i don't have to edit/patch the seam jar.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4042699#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...