> > 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
[EMAIL PROTECTED], 510-567-9957, http://ScienceTools.com/
