Re: Servlet thread safety in Tomcat

[kwirirai]

Thanks very much for your contribution guys! :-)
This has given me  new approaches to the problem.I intend to 
remodify,try the synchronization and do the testing/benchmarking.But 
this has made me think a lot about threading , it is really complicated 
, I have researched about it but never found a clean solution to 
multithreading in my apps.Initaly I thought with servlets I dont have to 
wory about the threading issue, now I know its everywhere.
I realy have todo a lot of testing.

Shapira, Yoav wrote:

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]