Milt Epstein wrote:
> On Thu, 2 Nov 2000, Andras Balogh wrote:
>
> > Hi,
> >
> > I would say DO NOT implement it. It will slow down your servlet
> > very much. The only thing you have to do is be sure that your
> > (multi threaded) servlet to be thread save. I can't understand 100%
> > what means thread safe but you will have to take care about accesing
> > global variables.
> > If you acces (or modify) a global variable than you have to
> > syncronize that block of code. Aslo you can syncronize a method.
> > You can modify any object created in the service (doGet or doPost)
> > because this will be thread safe.
> > My advice is don't use STM and search the archives (i have seen
> > on this list much better explanations about thread safe issues) or
> > in books how to make your servlet thread safe.
>
> I strongly concur, and many people on the list have also suggested
> likewise when this has come up in the past.
>
> SingleThreadModel is misleading in that it doesn't guarantee thread
> safety in all situations, and there are some unintuitive consequences
> to using it (e.g. the servlet container may create multiple instances
> of the servlet, to help compensate for the performance penalty).
>
> The best solution is to design your servlet so that it is thread safe,
> and/or isolate the necessary synchronization to the smallest possible
> code blocks.
>
The following is just my guessing :-) :
0
perhaps [SingleThreadModel] is not very [effective:-)] , because perhaps
[SingleThreadModel] will [lock the whole "service/doGet/doPost" method :-) ] , so
if we
[focus on effectiveness], perhaps we need to [lock part of the code in
"service/doGet/doPost"].
1
but I guess perhaps [SingleThreadModel] is a sulotion which is supported
by [all Servlet engine providers], so if we want to make our Servlet class
[portable/or suitable to every case -- for example, multi ClassLoader or ...],
then perhaps [SingleThreadModel] is a [standard way] :-) otherwise
our servlet class perhaps will be [non_portable over diferrent Servlet engines],
or [sometimes works well, but when many clients access co-currently, it will
not work well :-) ] . -- only my [guessing], now I don't have any testing to
prove
it :-) :-) :-)
Bo
Nov.02, 2000
___________________________________________________________________________
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