>>> Bo Xu <[EMAIL PROTECTED]> 03-Nov-00 10:08:37 PM >>>
>because now *counter* and *lock* are instance field, so
>if there are a instance pool which includes several instances
>of the class Counter, now diferrent thread will be made
>by diferrent instance, and so they will use diferrent
>*lock* to lock the code, and so now perhaps there
>are more than one threads will run the same code
>co-currently. and now I guess the sum of all counter
>is the accessing time we want to get.
i) as Craig explained, instance pools are ONLY used when you have a
servlet which implements SingleThreadModel. The reason for that is to
try and increase throughput to such Servlets.
The spec is explicit about having ONLY ONE instance of a servlet for
each:
<servlet>...</servlet>
decleration in the web.xml.
ii) if there IS more than one instance then you're right that there
will be different locks... BUT there will also be different counter
variables (duh! /8-)
>and several weeks ago I think if I use static class field,
>I can solve this problem. But form several emails, for
>the same Servlet class, perhaps it will be loaded by
>diferrent ClassLoader, so now I guess we will have
>more than one static class field. For example, in this
>case, if we use *static int counter* and/or *static Integer
>lock* , we will have several *lock* and *counter* , and
>perhaps the sum of all of the counter is the accessing
>time we want to get.
Yes. It's true that static will do that.
That's why I DIDN'T USE STATIC in my example.
>so sevaral days ago I hope the Sevlet engine provider
>will give us a solution , and I guess the interface
>SingleThreadModel perhaps is a standard way. :-)
You keep saying this... I've just shown you the solution without
having to use SingleThreadModel.
I'm a member of the team that develops the API (so is Craig). I'm
telling you (and so was he) that SingleThreadModel is NOT designed to
be the solution to the problem you think it is.
Honestly.
>but I don't have a testing
You don't need to test this - the spec defines it.
The people who build containers (including myself and Craig) follow
the spec when building them.
>* I also can lock my code by both:
> [a] static synchronized method (which uses the only one
> class which is loaded by the ClassLoader)
> [b] synchronized method (which use the only one instance)
All a servlet engine does to provide the SingleThreadModel behaviour
is wrap the servlet's service() call in a block synchronized on the
servlet.
Something like this:
synchronized(theServlet)
{
theServlet.service(request,response);
}
So this has the same effect as you putting "synchronized" on one of
your servlet's request methods (eg:
service(ServletRequest,ServletResponse) ). That's why you shouldn't do
it that way... because it's not making your servlet thread safe...
it's making it non-threading.
>But I think such testing is not enough, because I guess perhaps
>other Servlet engines will use instance pool or something else to
>improve the performance. so the day before yesterday I suggest
>to make a testing together :-)
Again... read the spec. Contatiners do not use instance pools EXCEPT
when dealing with SingleThreadModel servlets.
Nic
___________________________________________________________________________
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff SERVLET-INTEREST".
Archives: http://archives.java.sun.com/archives/servlet-interest.html
Resources: http://java.sun.com/products/servlet/external-resources.html
LISTSERV Help: http://www.lsoft.com/manuals/user/user.html
