You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by eric leung <ch...@yahoo.com> on 2001/04/13 01:02:39 UTC
Servlet -- SingleThreadModel
I have a servlet implements the SingleThreadModel
Interface. But this servlet has problem handle more
than 1 request at a time.
Since I have 1 person on host1 upload a big file ( >
20MB ) to the servlet. When the 2nd person on host2
send a request to that servlet. The servlet will not
response.
Any one had the same problem using SingleThreadModel?
I am using apache 1.3.17 + tomcat 3.2.1.
thanks.
P.S. I use SingleThreadModel beause i don't want to
worry about syncronization of threads, I have
Connection as instance variable:
public class admin extends HttpServlet implements
SingleThreadModel{
private PrintWriter out;
private OracleConnectionCacheImpl pool;
private Connection conn;
private Statement stmt;
..etc...
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Servlet -- SingleThreadModel
Posted by Tim O'Neil <ti...@xythos.com>.
At 12:42 PM 4/13/2001 -0500, you wrote:
>You can't really avoid dealing with concurrency issues in Java. The
>best thing to do is to just bite the bullet, learn what you need to
>about concurrency, analyze your code, and make it handle it as
>best/easily as possible. Avoid concurrency issues as much as
>possible, and when unavoidable, limit it to the smallest block
>possible and synchronize it.
Besides, concurrency in Java is not that bad.
Think about if you had to do this in C. Sun.com
is full of useful little thread action examples.
Do some research.
Re: Servlet -- SingleThreadModel
Posted by Jeff Kilbride <je...@kilbride.com>.
That's the whole point of SingleThreadModel, ensuring only one request
accesses a given servlet instance at any one time. Check the javadoc:
http://tomcat.mslinn.com/jsp22_servlet11/index.html
To handle more than one request at a time, the servlet container uses a pool
of instances of the servlet that implements the SingleThreadModel interface.
However, if your "Connection" resource, the one you're trying to
synchronize, can only be used by one servlet instance at a time,
SingleThreadModel pooling is not going to help you. The servlet instances in
your pool are going to "line up" behind the one currently using your
"Connection" resource.
What kind of "Connection" are you trying to synchronize? Are you limited to
having only one "Connection" at any one time? If so, your bottleneck is your
"Connection" resource and not the SingleThreadModel interface.
Maybe if you post some of your code, we can help you figure out a better way
to implement it.
Thanks,
--jeff
----- Original Message -----
From: "eric leung" <ch...@yahoo.com>
To: <to...@jakarta.apache.org>; <da...@convio.com>
Sent: Thursday, April 12, 2001 5:12 PM
Subject: Re: Servlet -- SingleThreadModel
> David,
> Thanks your suggestion.
>
> But I don't think this is a good solution. i have
> already 50Kb of code in that servlet class. if i need
> to move it to another class. that will be alot of
> work.
>
> My question is why implement SingleThreadModel
> interface can't handle more than 1 request at a time?
> Since i will have only 3 clients. I think
> SingleThreadModel is the best solution, without the
> need to worry about threading issue.
>
>
> --- David Crooke <da...@convio.com> wrote:
> > Make your connection etc. stack variables instead,
> > by creating a class
> > to contain them and move all your code into that
> > class - then have the
> > empty servlet "new" an instance and call the service
> > method. This way
> > you can use instance variables and the
> > Multi-Threaded Model.
> >
> > eric leung wrote:
> >
> > > I have a servlet implements the SingleThreadModel
> > > Interface. But this servlet has problem handle
> > more
> > > than 1 request at a time.
> > >
> > > Since I have 1 person on host1 upload a big file (
> > >
> > > 20MB ) to the servlet. When the 2nd person on
> > host2
> > > send a request to that servlet. The servlet will
> > not
> > > response.
> > >
> > > Any one had the same problem using
> > SingleThreadModel?
> > > I am using apache 1.3.17 + tomcat 3.2.1.
> > > thanks.
> > >
> > > P.S. I use SingleThreadModel beause i don't want
> > to
> > > worry about syncronization of threads, I have
> > > Connection as instance variable:
> > >
> > > public class admin extends HttpServlet implements
> > > SingleThreadModel{
> > > private PrintWriter out;
> > > private OracleConnectionCacheImpl pool;
> > > private Connection conn;
> > > private Statement stmt;
> > >
> > > ..etc...
> > >
> > >
> > > __________________________________________________
> > > Do You Yahoo!?
> > > Get email at your own domain with Yahoo! Mail.
> > > http://personal.mail.yahoo.com/
> >
> > --
> > David Crooke, Chief Technology Officer
> > Convio Inc. - the online partner for nonprofits
> > 4801 Plaza on the Lake, Suite 1500, Austin TX 78746
> > Tel: (512) 652 2600 - Fax: (512) 652 2699
> >
> >
> >
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
>
Re: Servlet -- SingleThreadModel
Posted by eric leung <ch...@yahoo.com>.
David,
Thanks your suggestion.
But I don't think this is a good solution. i have
already 50Kb of code in that servlet class. if i need
to move it to another class. that will be alot of
work.
My question is why implement SingleThreadModel
interface can't handle more than 1 request at a time?
Since i will have only 3 clients. I think
SingleThreadModel is the best solution, without the
need to worry about threading issue.
--- David Crooke <da...@convio.com> wrote:
> Make your connection etc. stack variables instead,
> by creating a class
> to contain them and move all your code into that
> class - then have the
> empty servlet "new" an instance and call the service
> method. This way
> you can use instance variables and the
> Multi-Threaded Model.
>
> eric leung wrote:
>
> > I have a servlet implements the SingleThreadModel
> > Interface. But this servlet has problem handle
> more
> > than 1 request at a time.
> >
> > Since I have 1 person on host1 upload a big file (
> >
> > 20MB ) to the servlet. When the 2nd person on
> host2
> > send a request to that servlet. The servlet will
> not
> > response.
> >
> > Any one had the same problem using
> SingleThreadModel?
> > I am using apache 1.3.17 + tomcat 3.2.1.
> > thanks.
> >
> > P.S. I use SingleThreadModel beause i don't want
> to
> > worry about syncronization of threads, I have
> > Connection as instance variable:
> >
> > public class admin extends HttpServlet implements
> > SingleThreadModel{
> > private PrintWriter out;
> > private OracleConnectionCacheImpl pool;
> > private Connection conn;
> > private Statement stmt;
> >
> > ..etc...
> >
> >
> > __________________________________________________
> > Do You Yahoo!?
> > Get email at your own domain with Yahoo! Mail.
> > http://personal.mail.yahoo.com/
>
> --
> David Crooke, Chief Technology Officer
> Convio Inc. - the online partner for nonprofits
> 4801 Plaza on the Lake, Suite 1500, Austin TX 78746
> Tel: (512) 652 2600 - Fax: (512) 652 2699
>
>
>
__________________________________________________
Do You Yahoo!?
Get email at your own domain with Yahoo! Mail.
http://personal.mail.yahoo.com/
Re: Servlet -- SingleThreadModel
Posted by David Crooke <da...@convio.com>.
Make your connection etc. stack variables instead, by creating a class
to contain them and move all your code into that class - then have the
empty servlet "new" an instance and call the service method. This way
you can use instance variables and the Multi-Threaded Model.
eric leung wrote:
> I have a servlet implements the SingleThreadModel
> Interface. But this servlet has problem handle more
> than 1 request at a time.
>
> Since I have 1 person on host1 upload a big file ( >
> 20MB ) to the servlet. When the 2nd person on host2
> send a request to that servlet. The servlet will not
> response.
>
> Any one had the same problem using SingleThreadModel?
> I am using apache 1.3.17 + tomcat 3.2.1.
> thanks.
>
> P.S. I use SingleThreadModel beause i don't want to
> worry about syncronization of threads, I have
> Connection as instance variable:
>
> public class admin extends HttpServlet implements
> SingleThreadModel{
> private PrintWriter out;
> private OracleConnectionCacheImpl pool;
> private Connection conn;
> private Statement stmt;
>
> ..etc...
>
>
> __________________________________________________
> Do You Yahoo!?
> Get email at your own domain with Yahoo! Mail.
> http://personal.mail.yahoo.com/
--
David Crooke, Chief Technology Officer
Convio Inc. - the online partner for nonprofits
4801 Plaza on the Lake, Suite 1500, Austin TX 78746
Tel: (512) 652 2600 - Fax: (512) 652 2699
Re: Servlet -- SingleThreadModel
Posted by Bo Xu <bo...@cybershop.ca>.
eric leung wrote:
> I have a servlet implements the SingleThreadModel
> Interface. But this servlet has problem handle more
> than 1 request at a time.
>
> Since I have 1 person on host1 upload a big file ( >
> 20MB ) to the servlet. When the 2nd person on host2
> send a request to that servlet. The servlet will not
> response.
>
> Any one had the same problem using SingleThreadModel?
> I am using apache 1.3.17 + tomcat 3.2.1.
> thanks.
>
> P.S. I use SingleThreadModel beause i don't want to
> worry about syncronization of threads, I have
> Connection as instance variable:
>
> public class admin extends HttpServlet implements
> SingleThreadModel{
> private PrintWriter out;
> private OracleConnectionCacheImpl pool;
> private Connection conn;
> private Statement stmt;
>
> ..etc...
> [...]
Hi :-) from several emails in Servlet-List and this List, perhaps
it is better Not to use the following:
- SingleThreadModel
- public synchronized void service/doGet/doPost(...){...}
(the above two are simialr)
*0 because in fact, the above 2 all use "this(instance) of MyServlet"
to lock the code, But if:
- we have more than one servlet-defination in WEB-INF/web.xml,
now in fact we can not be sure about the "synchronized"
- if the Servlet container supports "instance pool" for
SingleThreadModel,
we also can not be sure about the "synchronized".
- if the Servlet container Doesn't support "instance pool" for
SingleThreadModel,
now perhaps the performence is not good if we use SingleThreadModel
*1 so I guess the shortcoming of the above 2 are:
- lock All code in service/doGet/doPost, in fact, perhaps we don't need
to lock all of them
- in some cases, even if MyServlet implememts SingleThreadModel, we
still can not be sure about "synchronized"(discussed in *0)
*2 so I suggest: perhaps it is better to use a "locker" to "lock and
only-lock" the
code segment which must to be locked -> we don't need to lock all
the code,
so now I need a locker: for example, we can use the following as a
locker:
- a instance field or a static field in MyServlet:
%private (static) byte[] locker=new byte[0];
%private (static) Object locker=new Object();
- "this"(the instance object of MyServlet)
- "this.getClass()"(the Class object of MyServlet in webapp
classloader,
with TOMCAT, and if omitting the auto-reloading, it is Only-One)
- ServletContext, with TC, it is Only-One within webapp.
- MyHelper class
% its instance(SingleTon or Non-SingleTon)
% its Class object
% its instance/static field
*3 the following are good emails :-)
*********************************** email0 ********************
See intermixed.
Bo Xu wrote:
> Gokul Singh wrote:
>
> > ----- Original Message -----
> > From: "Bo Xu" <bo...@CYBERSHOP.CA>
> >
> > > * SingleThreadModel is non_multi-thread: so it is thread-safty
but it
> > is not
> > > multi-thread-safty. But we also can think it is the safest
way of
> > > multi-thread-safty :-)
> >
> > Single thread model is thread safe for the member variables of a
class, but
> > as the container *may* instantiate more than one instance, it is not
thread
> > safe for static variables, if any. Another fallback of this is if
you are
> > using a non static member variable, each instance will have it's own
copy
> > which may cause some problems e.g. if you used it to keep count of
the
> > number of hits.
> >
> > > * I guess if we use SingleThreadModel, the Servlet container
> > > will have to work *harder*, and the efficacy is
lower(because
> > > now for a Servelt class which implements
SingleThreadModel,
> > > at any time, only zero/one client can access it ). and
from
> > several
> > > emails, it is not good to use SingleThreadModel in a *real
> > > system*-> it is for testing(?) or other purpose.
> >
> > In a real environment, there can be N number of requests being
processed
> > simultaneously by a servlet (each being a seperate thread). But if
you use
> > SingleThreadModel, you limit the number of simultaneous request
being
> > processed to the number of instances created by the container, which
can
> > even be 1 !.
> >
> > > Bo
> >
> > Regds,
> > Gokul
> > [...]
>
> Hi Gokul, thanks for your email! :-) the following is my new
understanding
> of SingleThreadModel after I read your email:
>
> # if my Servlet class implements SingleThreadModel, then for every
Servlet
> definition,
> Servlet container will make a instance pool(which includes n
instances) from
> my
> Servlet class.
>
More precisely, the servlet container has the *option* to create such a
pool -- it
is not required. For example, Tomcat only creates one instance of your
servlet per
servlet definition, even if it implements SingleThreadModel.
>
> # so now:
> * Servlet container will use one instance in this pool to make
a thread
> for
> a new client accessing
> * and in any time( define by Newton, not by Einstein:-) ), we
can not
> find
> two threads which are from the same instance.
> * we will not have n+1 threads in any time.
>
> # so in fact SingleThreadModel is still similar with multi-thread,
but is a
> *limited*
> multi-thread-> every thread must from different instance in that
pool.
>
The easiest way to understand what SingleThreadModel does is to pretend
that you
declared your doGet() and doPost() methods to be synchronized -- within
any one
instance of your servlet, there will be at most one request active at
any given
time.
Obviously, this will have performance impact if your container provides
"N"
instances and you get "> N" simultaneous requests.
>
> Is the above right? please give me some directions!
>
My advice: do not use SingleThreadModel. My reasoning is this:
* The performance impact described above, when you have more
requests than instances.
* The synchronization that is performed to implement SingleThreadModel
is not free -- but you pay that price on every single request even if
it
is not needed.
* SingleThreadModel gives you the *llusion* of thread safety, because
you
can use instance variables in your servlet to store per-request state
information safely. However, it does not protect you from other
multi-thread
concerns:
- Static variables in your servlet class are still accessible from
multiple
threads at the same time, if your container has instance pooling.
- Sessions and their attributes can still be accessed from multiple
requests simultaneously, so you still have to worry about it.
* Locking at the doGet() or doPost() method is more coarse-grained than
most applications really need. In most cases, you only really need to
lock around simultaneous access to shared resources -- but
SingleThreadModel
doesn't give you that option.
* Instance pooling is not a required feature means that my
application will behave very differently on containers that provide
instance
pools versus those that do not.
The best approach is to write your servlets in a thread-safe manner in
the first
place -- then the only limit on how many simultaneous requests you can
handle is
the maximum number of threads your JVM will support, with no artificial
restrictions because of synchronization at the per-servlet-instance
level.
>
> Thanks in advance!
>
> Bo
> Dec.08, 2000
>
Craig McClanahan
*********************************** </email0> ********************
*********************************** <email1> ********************
On Fri, 23 Mar 2001, Pradeep Kumar wrote:
> The Servlet specification says that, that the container should
guarantee only
> one instance of the servlet. However some of the container do maintain
a
> small of pool of servlet instances and manage them. For example there
are 3
> instances of a servlet in the pool, and if there are 300 requests,
each
> instance spawns off 100 threads for 100 requests.
> I don't know how far this is true with Tomcat. In general you should
not make
> any assumptions about the number of instances of your servlet.
>
Maintaining instance pools is *only* allowed for servlets that implement
the SingleThreadModel interface. Otherwise, the container is required
to
provide exactly one instance of the servlet per servlet definition
(i.e. either the <servlet> declaration in your web.xml file, or a
dynamically created definition when you call /servlet/{servletname}).
Tomcat does not currently implement instance pooling for
SingleThreadModel
servlets, although it could legally do so.
> pradeep
>
Craig McClanahan
*********************************** </email1> ********************
Bo
Apr.13, 2001
Re: Servlet -- SingleThreadModel
Posted by Milt Epstein <me...@uiuc.edu>.
On Thu, 12 Apr 2001, eric leung wrote:
> I have a servlet implements the SingleThreadModel Interface. But
> this servlet has problem handle more than 1 request at a time.
>
> Since I have 1 person on host1 upload a big file ( > 20MB ) to the
> servlet. When the 2nd person on host2 send a request to that
> servlet. The servlet will not response.
>
> Any one had the same problem using SingleThreadModel? I am using
> apache 1.3.17 + tomcat 3.2.1. thanks.
>
> P.S. I use SingleThreadModel beause i don't want to worry about
> syncronization of threads, I have Connection as instance variable:
[ ... ]
As has been posted, using SingleThreadModel is a bad idea. There has
been a lot of discussion of it on Sun's servlet-interest list. For
one thing, it does not allow you to not have to worry about threading
issues. In this way, it is quite misleading. It only really protects
you from certain kinds of threading issues, it is far from a cure-all.
And it has perforamnce implications, as you've seen.
You can't really avoid dealing with concurrency issues in Java. The
best thing to do is to just bite the bullet, learn what you need to
about concurrency, analyze your code, and make it handle it as
best/easily as possible. Avoid concurrency issues as much as
possible, and when unavoidable, limit it to the smallest block
possible and synchronize it.
Milt Epstein
Research Programmer
Software/Systems Development Group
Computing and Communications Services Office (CCSO)
University of Illinois at Urbana-Champaign (UIUC)
mepstein@uiuc.edu