Mark, >> Contended locks are much slower, so it's important to know. > > It was contended. I have added the uncontended figures: 75ns and 225ns.
What do the two different values mean? Also, did your +50ns figure mean that the /overhead/ was +50ns, or that waiting for the "other" thread to release the lock (which would include execution of the method itself) took 50ms longer. Since those threads cannot really run concurrently due to the synchronization, your timing should be affected by that fact, instead of merely the added overhead. > 150ns per request (on my hardware) is still probably more than we want > to add to every request. Really? If you say so... >> Are Tomcat sessions pluggable? >> [snip] > That would work. However (and this is just my view) making it an > optional feature of the standard implementation would be less work, > easier to maintain and less prone to user configuration error. Yeah, but there were people begging not to add another configuration option. It's got to be a config option in either case. > I agree it needs to be fixed. As do the other 180 odd currently open > bugs ;) Fair enough, but this one is easy. It's not like it's going to take weeks of full-time work to develop and test a fix for this bug. > Performance is something that does get a fair amount of > attention from the Tomcat committers and the fix for this needs to > keep that in mind. From my perspective this is a feature/performance > trade-off where we can provide a configuration option for users to > make their own decision. I understand the focus on performance, but this is a straight-up bug. Their tag line ought not to be "Tomcat: doesn't work, but boy is it fast". :( -chris
signature.asc
Description: OpenPGP digital signature
