Re: Understanding Implements

Daniel Eyers wrote:

>I know I have a class called myClass
>that inherits from HttpServlet.  I also
>know that implementing SingleThreadModel
>changes the way the HttpServlet is
>handled by WAS.

This highlights yet another use of the interface concept that seems
specific to Java.

There are a couple of "interfaces" that are more stylistic conventions or
functional agreements than true interfaces.  I think this is an example of
one.

Basically, the default and formal definition of servlet is such that you
can have multiple threads against the servlet object.  I always found this
an odd definition, but that's what we have.  So, you can't rely on any
variables in the servlet as "instance" variables without a lot of
synchronizing methods.

While I haven't deployed major servlets of my own yet, my usual approach is
to have a "shadow" object that corresponds to each servlet and then the
servlet proper doGet/doPut code consists largely of constructing the
"shadow" object, including the input and output stuff that came in as
input.  I then provide a "run" method or some such on the shadow object and
away it goes.  In this way, I can have ordinary instance variables that are
threadsafe, because I can put the reference to my "shadow" object on
"thread local stack" storage in my doGet or doPut method.

Given that easy technique, SingleThreadModel is something I haven't
bothered with.  The fact that I do performance for a living influences me
some here, but SingleThreadModel seems to be a very drastic approach that
lets you know you have exactly one copy of the servlet hanging about (or,
at least that's how I read the manual on Servlets where this is described).
This lets you use class and instance variables without synchronization, but
it seems a bit too restrictive to me; doesn't scale.  Of course, the main
effect of this is to signal to WebSphere how you expect to be invoked.

So, even if I don't like it much, SingleThreadModel is a good example of
how very simple interfaces can be used as cues to change behavior of Java
classes.  Another "implements" that seems really for others to look at is
the "Serializable" interface which actually seems to be a signal to the JVM
to permit the object to be "deflated" and written out to a byte stream in
certain circumstances (Serializable actually seems to cheat a bit in that
it allows a default implementation to be provided for the interface by
Java, but it is a very basic function, so it makes sense).


Larry W. Loen  -   Senior Java and AS/400 Performance Analyst
                          Dept HP4, Rochester MN


+---
| This is the JAVA/400 Mailing List!
| To submit a new message, send your mail to JAVA400-L@midrange.com.
| To subscribe to this list send email to JAVA400-L-SUB@midrange.com.
| To unsubscribe from this list send email to JAVA400-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: joe@zappie.net
+---