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#4042699

Reply to the post : 
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4042699
_______________________________________________
jboss-user mailing list
[email protected]
https://lists.jboss.org/mailman/listinfo/jboss-user

Reply via email to