On Mon, 17 May 1999, Craig R. McClanahan wrote:
.....
> I agree with Jon that STM is a bad thng.
>
> All harshness aside, there are multi-thread issues that SingleThreadModel does
> not address. Programmers that rely on it because they don't know how (or don't
> want to know how) to write multi-thread-safe code will usually get bit on one
....
Hi,
I would like a "SingleInstanceServlet" interface,
in order to force servlet engine NOT to create multiple
instances of a certain servlet.
This would guarantee that all concurent requests share the same
local variables.
Probably this model (hypotetic SingleInstanceServlet)
should also force distributed servlet engines to load these servlets
only in one JVM
Fortunately with JSDK 2.1 one can use ServletContext for such purposes,
but still:
- access to local variables is faster than keyed-lookup.
- local variables can be protected from other servlets,
while ServletContext's atributes are all public.
Bye
Cezar
>
> * Performance -- for toy projects, or during development, you often
> don't see this one, but it shows up when you put a multiuser app
> into production. Partial solution -- configure your servlet engine for
> multiple instances, but this leads to the next problem.
>
> * Information sharing -- 99.9% of new servlet authors seem to think
> that STM means there will be only one instance of the servlet, but
> that is not necessarily the case. In particular, you solve some of the
> performance issues by telling your servlet engine to create more than
> one of them. Even with STM, you can not rely on using instance variables
> in your class as globals.
>
> * Multiple users -- Even if STM solves particular programming issues
> for you, servlets operate in a multiple-user environment. You still have
> to worry about things like two users modifying the same data at the
> same time. You can't hide from multi-threading, and the requirement
> to properly synchronize access to shared objects.
>
> STM encourages developers to believe that they don't have to worry about
> multithreading. This leads to disappointment and required redesigns when you
> run into cases where your assumptions are violated. Much better would be to
> train new servlet programmers to program in a multithreaded manner from the
> first moment.
>
> This is where the experts have some responsibility -- we need to make sure that
> the examples we create demonstrate thread safe techniques. Servlet book
> authors need to emphasize thread safety in their tutorials and explanations --
> and demonstrate how to program it correctly. Development managers need to
> insist that thread-safe techniques be used on the projects they are building.
> Above all, it is the responsibilty of API designers to avoid tempting people to
> take the "easy" way out, without solving *all* of the related problems.
>
> But new servlet developers have a responsibility also -- you need to commit
> yourself to learning how to properly use the tools you are working with.
> Otherwise, you will perpetuate the bad reputation that software developers
> carry in the real world, for creating stuff that just does not work.
>
> Craig McClanahan
>
> ___________________________________________________________________________
> 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
>
___________________________________________________________________________
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
