Howdy, >Synchronization does produce overhead, but it's what you *must* do if >you will not re-write your servlets to no longer contain instance >fields, *and* you wish to provide thread safety.
Well-put. And you might be pleasantly surprised at how small the overhead is. Which is why I always suggest testing/benchmarking ;) >There is a mode, and you have mentioned it before.. It's not a Tomcat >mode, it's that "Single threaded" thing. (see, I can't even write it >correctly, I don't even know what the exact name is). It's SingleThreadModel, which is deprecated (with no replacement) in the latest version of the servlet specification. So even if you're not using it already, don't start now. >If the request that wants the 300 emails is taking "too long" (as >decided by the container), then that user's request thread is suspended, >while the other user's requests are handled. That's the whole point of >multi-threading the servlet... (so that requests don't pile up)? That's not done by tomcat: all requests have equal priority from the Tomcat point of view. But the OS and JVM implement preemptive multitasking, and will split CPU time between the threads. So you're right Mike, if request A takes a very long time, and request B starts after request A, request B does NOT have to wait until request A is done to get CPU time. Yoav Shapira This e-mail, including any attachments, is a confidential business communication, and may contain information that is confidential, proprietary and/or privileged. This e-mail is intended only for the individual(s) to whom it is addressed, and may not be saved, copied, printed, disclosed or used by anyone else. If you are not the(an) intended recipient, please immediately delete this e-mail from your computer system and notify the sender. Thank you. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
