Greg Barish wrote:
> Hello -
>
> Anyone feel like a challenge?
>
> I am still having problems trying to get Apache & JServ to scale to even
> 10 simultaneous connections on Solaris when I'm using a sychronized doPost().
>
> Before I get into a description of the problem, it would seem to me that
> JServ should be able to queue up connections to doPost()'s which need
> to be serialized. Can someone tell me what it _should_ do for such cases?
> Suppose 1000 clients attempt to POST on a servlet which has a synchronized
> doPost() that takes over a minute to complete? What _should_ happen?
[remainder of the example snipped]
This one isn't that tough, once you understand what's going on. The bottom
line: do not synchronize doPost() (or service(), or doGet()) if you expect
scalable performance in *any* servlet engine.
Why? Because, in most servlet engines, the engine creates a single instance of
your servlet and tries to invoke it on multiple threads (to handle simultaneous
requests). If your doPost() is not synchronized, this works great -- but by
adding the "synchronized" tag, you are effectively single threading the requests
through that one instance.
What if you *really* need a synchronized doPost() method? (This is really a
fundamental design issue, but I will assume for a moment that you have a valid
reason for wanting it.) The approved mechanism is to tag your servlet as
implementing the SingleThreadModel interface, and then removing the
"synchronized" tag. The servlet engine promises to avoid invoking the service
method (which indirectly calls doPost) more than once for a particular instance
of your servlet. To support scalability, the servlet engine creates more than
one instance (by default, Apache JServ starts five, but you can ask for what you
need).
This still causes you a design problem if you are relying on instance variables
in your servlet being shared across all requests (because there will be one copy
per instance). If this is the case, I really suggest you go back to the drawing
board on designing applications for a multithreaded environment, to avoid the
need for synchronization in the first place.
Craig McClanahan
----------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
