cocoon-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <>
Subject Re: Are XSP Pages singletons?
Date Sat, 02 Sep 2000 14:35:39 GMT
Ed Staub wrote:
> Stefano and Matt,
> I wrote earlier:
> > In other words, can class variables be used dynamically without fear of
> > thread collision?
> Sorry, I was not clear, let me try again!
> By "class variable" I meant "instance variable", i.e., a non-static variable
> declared at the class level.
> Stefano wrote:
> >And, anyway, servlets are not singletons at all: it's up to the
> >container to choose how many instances there are if you don't implement
> >SingleThreadModel (which is totally stupid and many of us on the Servlet
> >API JSR want to deprecate)
> This has me really confused!
> The Servlet 2.2 spec says in section 2.3:
> "By default, there must be only one instance of a servlet class per servlet
> definition in a container.

Yes, yes, I used the term "container" incorrectly. In the spec
"container" is a servlet context, I used "container" to name the engine.
Sorry, my mistake.

> In the case of a servlet that implements the
> SingleThreadModel interface, the servlet container may instantiate multiple
> instances of that servlet so that it can handle a heavy request load while
> still serializing requests to a single instance.

This is what some of us want to deprecate: it's clearly misleading since
there is nothing in a normal servlet to removes the ability to stand
heavy request load while still behavior properly, it's just a matter of
good concurrent programming practice 

SingleThreadModel was introduced as a way to allow newbie servlet
writers to fix concurrency problems by simply having the servlet
container give a new instance to each different thread, but clearly
enforces bad server side programming practices and doesn't really help
performance (actually it decreases it)

> In the case where a
> servlet was deployed as part of an application that is marked in the
> deployment descriptor as distributable, there is one instance of a servlet
> class per servlet definition per VM in a container. 

This is another section where the spec is very bad. A servlet to be
"distributable" must follow very restrictive practices (for example,
avoid instantiating threads, accessing files directly, etc...), much
like the EJB spec declares for EJBs.

We are working on cleaning this up.

> If the servlet
> implements the SingleThreadModel interface as well as is part of a
> distributable web application, the container may instantiate multiple
> instances of that servlet in each VM of the container."

> So that's why I talked about singleton servlets.  Stefano, can you explain?
> Has normal practice advanced beyond the standard?

No, the problem is "container" definition: if a container is a JVM, then
the spec says that you can have one and only one servlet instance per
servlet class. This is correctly a singleton pattern.

If a container is a servlet sandbox and a JVM can have many containers
(like normally happens for ISPs, for example), then you can have many
instances of the same servlet class (for example, two Cocoons running),
but only one per sandbox.

So, a servlet is a singleton in a sandbox, but it's may not be in a
servlet engine.

Sorry, I should have stated by terminology clearer. Anyway, the spec
says that "container" equals "sandbox" NOT "servlet engine".

Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<>                             Friedrich Nietzsche
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------

View raw message