Re: SERVLET-INTEREST Digest - 19 May 2001 to 20 May 2001 (#2001-1 41)

[Jo�o Robertson Kramer Santana]

        I would like to remember that using SingleThreadModel does not
garantue sincronization in other objects, only on class variables. What i
mean is that if your system has a object that is shared by a group of
servlets, making then SingleThreadModel does not guarantee syncronization on
this object. It does not guarantee syncronization on static variables
either.

        I personally prefer not to use SingleThreadModel, and instead
control the exact points where the syncronization is needed.

        bye

                jk



Date:    Sun, 20 May 2001 23:08:32 -0700
From:    Rob L'Estrange <[EMAIL PROTECTED]>
Subject: SingleThreadModel

Hi All

I'm after some feedback from the group. We're thinking of implementing our
servlets using the SingleThreadModel interface. We have no concerns about
concurrency; we're actually thinking of doing it so that each servlet can
have sole usage of its own (class-level) instance vars. We understand (and
have used) alternatives (eg. an inner class to hold state, a seperate class
to contain state and even processing, etc), but we like the pooling
advantages that come with marking our classes as SingleThreadModel.

Why are we wanting to do something like this? All of our servlets implement
an interface that models the tasks performed by a server side program that
satisfies a HTTP request. The interface consists of a number of methods that
represent a 'request satisfaction lifecycle'. To us, this makes much more
sense than stuffing everything you want to do into a doGet() or doPost().
This means that our servlet code traverses a number of methods, and this
means that we need to share data across method calls. There are many
strategies for doing this (I've listed a couple earlier in this post, and
it's not hard to think of others), but we'd prefer to take the approach that
you usually take in a class - that is, handle state across method calls by
storing state in the class' instance vars. This is why the SingleThreadModel
interface makes sense to us - particularly when our vendor (Web Logic 6)
uses pooling to manage multiple instances of each SingleThreadModel servlet.
This is a performance advantage you do not get, for instance, if you use an
inner or external class to store state.

We can see three negatives with this strategy:
1. More memory will be consumed by our web application as a result of
mulitple instances of each servlet existing in pools.
2. There will be occasional performance hits when pools manage their size
(particularly size increases) to suit demand. This can be managed to a
certain extent with a healthy initial pool size (at the expense of greater
memory usage of course).
3. Our understanding is that not all servlet container vendors handle (or
are required to handle) SingleThreadModel servlets in the same way (ie. by
using pools). That means we're introducing a bit of vendor tie-in.

We don't view the consumption of additional memory as an issue.

Our website is an ecommerce portal that will not be overly hit-intensive (it
deals with plant equipment sales, rather than high volume stuff like small
item sales to the general public).

I'm after general feedback and thoughts from the group, plus any specific
feedback from people who have used a similar strategy or addressed similar
issues. What do you think of the strategy? Can you see potential problems?
Have you successfully used such a strategy? Or, have you used the strategy
and found problems? Any and all feedback welcome.

Thanks
Rob

PS. If you're after more info on how SingleThreadModel servlets are handled
in Web Logic:
http://e-docs.bea.com/wls/docs60////servlet/progtasks.html#threadingissues

___________________________________________________________________________
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