RE: SingleThreadModel only giving 1 thread

[Edward Ivanovic <ed...@agent-ware.com>]

Hi Troy,
Sorry I didn't get around to replying earlier.
I'm stopped using Tomcat and replaced it with the Jetty server from
http://www.mortbay.org/

It addresses the issues/problems with the SingleThreadModel, cookies, and
host name resolution - all of which I was having problems with when using
Tomcat.
It's also open source and licensing is very similar to Tomcat's.

As for the SingleThreadModel issues, without wasting too much time on a
topic that I'm sure has already been discussed to death here I'll just say
that pooling SingleThreadModel servlets becomes very convenient when dealing
with certain 3rd-party products that may be single threaded and don't have
built-in pooling for the resources.  So rather than writing a pooling
container and wrappers around these classes is becomes much easier to
implement the SingleThreadModel and have the server pool those.  Transaction
management and variable sharing also becomes easier.  I'm obviously talking
about a transaction server rather than a HTML/JSP server.
Resources can still be shared using static methods/variables and focus can
be given there to synchronize appropriately.

This being a technical issue rather than one of opinion, I'd be very
interested in reading any publications/papers on why the SingleThreadModel
is bad.  If it's so bad then I must be missing something.  I'd like to know
the reasons so that I can change my code to stop using this Java feature.

I'm sure the people at Sun, IBM, bea (WebLogic), Oracle, and many others
would also be interested since they've all decided to implement the
SingleThreadModel pooling.


-----Original Message-----
From: Richard Troy [mailto:rtroy@ScienceTools.com]
Sent: Friday, October 19, 2001 2:50 PM
To: tomcat-user@jakarta.apache.org
Subject: Re: SingleThreadModel only giving 1 thread




> > I'm using Tomcat 4.0 and have a servlet that implements
SingleThreadModel.
> > In every other app server I've tried (WebSphere & WebLogic) multiple
> > instances of this servlet are created and handle concurrent requests.
> >
> > However, in Tomcat it only creates one instance of the servlet and other
> > users must wait to be processed. i.e. only 1 user at a time is served.
> >
>
> SingleThreadModel is a horrible API because it totally misleads people
> about thread safety.  Therefore, I don't believe in encouraging people to
> use it by doing any more than the spec requires -- although anyone who
> wants to is welcome to submit a patch to Tomcat to make is support
> instance pooling for STM servlets.
>

Hmmm... As a long-time operating systems programmer, I really get why you
might want a single-threaded section of code. From what I read of Tomcat's
behavior with single-threading, it appears to be 'a' correct
implementation, not 'the' correct implementation. To gage what would be
the 'better' solution depends on what you intend to do with it. Generally
speaking, the two primary uses of single-threading are to help ensure that
a given data-structure (or single datum) isn't inappropriately
concurrently accessed by another thread - thereby causing inappropriate
behavior- or to enforce a particular timing coordination. Traditionally
single-threaded sections are implemented with a signaling mechanism and
strategies varry - take your pick: MUTEX, semaphore, flag, lock, (you
could even add inturrupts to this list - each of these with varying
enforcement) so that only one execution thread can munge through a
"critical section" at a time.

Using single-threading for enforcement of timing in the context of web
services, the Tomcat implementation is the only one that makes sense to
me, with exaclty (at most) one thread running that code at one time.
Creating duplicate instances of equally-empowered "single-threaded"
threads, as someone reported, doesn't appear to be a mechanism able to
enforce timing in a way that I can see as useful. It must also be realized
that the Tomcat implementation is limited to each Tomcat server - serve
your data from a cluster and you see the limited scope I'm talking about.
(Database access anyone?)

Considering methodologies to avoid concurrent update of data, 'scope'
really matters. In this context, the broadest scope I can easily imagine
(as a practical matter) of sensitive application data is that held in a
database. Traditionally, a database engine itself is your enforcement
engine, with a begin-transaction starting things off and a commit or
abort-transaction ending them. The DBMS will enforce one-at-a-time access
rules to ensure your data remains consistent. But, that presumes real
context for user interaction. One of the reasons the web model sucks as an
application deployment domain is that you have a hard time maintaining
context. Instead, the web is said to be "stateless" - which roughly
equates to some flavor of "context challenged." (Look at all the bullshit
people go through with the cookie kludge.) Much is to be said to the
benefit of the stateless model, but it means that each web page hit and
its transactions must be absolutely semantically complete. And that,
generally, means a real headache for applicaton developers. ...Of course,
good application design, even within the context of a traditional
application environment, should also be as concerned about short,
semantically complete transactions much as reasonably possible because of
concurrency and locking concerns.  ...But I digress...

What I'm really saying is that for web-based applications, because
everything is essentially a one-shot-deal, there isn't any clear utility
to single-threading database access. (Particular traditional, single-node
or node-coordinated, non-web applications excepted.)  The application
_has_ to play whatever context games we read about on this list where
developers consider session_ids and so forth. And be ready for that action
to be the end of it. That leaves the scope of Java variables between
servlets/JSPs as the only remaining reasonable concern for a
single-threading paradigm.

Regarding using single-threading to protecting in memory data, it's only
"publicly" scoped data that matters. If some particular concurrent threads
can't read or write the sensitive data, it's no issue, so variable scoping
rules help determine utility. Unfortunately, I'm just dipping my toes in
this particular ocean. I don't yet have first hand experience with the
scope of Java variables between servlets and applications. And, I'd love
to hear from some of you: What are the relative scopes of variables
defined within this Servlet/JSP world? Do "realms" have something to do
with this scope? Could it be that the multiple concurrent single-threaded
threads we read about permit a peculuar self-relative scoping behavior?
...Why else would you do that? -shrug-

RT

--
Richard Troy, Chief Scientist
Science Tools Corporation
rtroy@ScienceTools.com, 510-567-9957, http://ScienceTools.com/




--
To unsubscribe, e-mail:   <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>