"Christopher T. Beers" wrote:
> So know that I have two responses, one being to pass the object to other
> methods and one being to use a syncronized block.
>
> Lets start a discussion as to which is better?
>
There is no absolute answer to which is "better" (although you will nearly always
want to minimize locking to maintain good performance). You need to start with a
couple of application-related questions.
(1) Is the information of this object relevant to just this one request, or to
multiple requests?
If it's just related to one request, you are probably simplest off to make it a
local variable and pass it to any method that needs it. That way, you never have to
worry about synchronization or re-initializing it.
If it's related to more than one request, you need to store it someplace between
requests -- either as an instance variable of the servlet class, or using
HttpSession.putValue() -- but see the next question.
(2) Is the information of this object shared between users, or is it unique to a
user?
If it's shared between users, an instance variable can be convenient. For example,
you might store a connection pool object here, so that the individual users can
allocate a connection, use it, and return it. The "allocate" and "return"
mechanisms would be synchronized to avoid problems from simultaneous access -- this
is normally provided for by the connection pool object itself. IMHO, it is
generally not a good idea to make the caller of a class's methods responsible for
synchronization -- you should deal with it yourself.
If your information is unique to a user, you definitely do NOT want to use an
instance variable, because the different users will be scribbling on the same
object. Storing things in a session is a better idea in this case.
Note that, even if you're storing things in a session, you might still need to be
concerned about synchronization. Consider the following scenario:
* User submits a request to a servlet that runs
for quite a while.
* Servlet starts running this request
* User presses STOP and then starts a different
request to the same servlet
* Servlet starts running the second request
* Both requests are part of the same session,
so both of them are possibly accessing the
same session-stored objects at the same time.
Whether this matters or not is very much application dependent. For example,
reading stuff out of the session is generally never an issue. However, you do need
to be aware that simultaneous access is possible.
(3) What about SingleThreadModel?
Another approach people have tried is to declare that their servlet implements the
SingleThreadModel interface. If you do, the servlet engine promises not to have
more than one request inside the service() method of an instance of your servlet at
the same time. But this will generally eliminate the possibility for using instance
variables to share things, because the servlet engine will generally start up more
than one instance of your servlet to maintain performance.
Note that SingleThreadModel also does not solve the "simultaneous access to the
session objects" issue described above, because the two requests will be running in
different instances of your servlet -- but still running at the same time.
If multi-threading concepts are new to you, I strongly suggest that you go through
the Thread trails of the Java Language Tutorial
(http://java.sun.com/docs/books/tutorial), and/or review computer science books
about threading.
> Christopher T. Beers Systems Analyst Administrator I
Craig McClanahan
--
--------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
READ THE FAQ!!!! <http://java.apache.org/faq/>
Archives and Other: <http://java.apache.org/main/mail.html/>
Problems?: [EMAIL PROTECTED]
