On Fri, Jan 03, 2003 at 09:42:59PM +0100, Christian Bollmeyer (GMX) wrote:
> Am Freitag, 3. Januar 2003 09:56 schrieb Vikramjit Singh:
> > Yups thats true, that when a variable is static, and two threads
> > are accessing the static variable then the value of the variable
> > can be changed. But my dear, what i am saying is that in web
> > applications, the container takes part of the threading issues for
> > you, and where every user has got a different session for him.
>
> Sorry, but this is *utterly wrong*.
I think what he's trying to say here is that if you take
advantage of the servlet framework's session management stuff, you can
offload some degree of the thread hassles. While this is true, it
doesn't mean you can ignore threading issues. Quite the opposite.
All servlets - and that means all JSPs - are multithreaded by default.
They all must expect to handle multiple requests simultaneously.
I find the best route is to minimize threading issues as a
starting point; avoid using instance variables, avoid storing
persistent data in the JVM itself, favor pushing out into a database.
When you do use persistent data in the JVM, be selective and precise
about how you use it. Keep the points where threads can meet as
clearly and specifically defined as possible. Start by moving all
access to a shared resource out to separate methods. Determine if you
need to make those methods synchronized or not (see below).
Avoid unnecessary synchronization. Avoid unnecessary complexity
in the areas where you do synchronize (synchronization by itself is
hairy enough without added complications). Understand the basics of
threading and locking. For example, one gotcha a lot of people miss
is that while you may have multiple chunks of a class that are
synchronized, they all use the same lock. So if one method is
synchronized, no other synchronized method can be called while that
method is executing, even if those two synchronized methods have
nothing to do with each other. Ergo, you're better off keeping the
synchronized stuff all in one, separate class specific to bits that
need to be synchronized.
In general, it's a good idea to borrow other peoples' brains for
this sort of thing. The easiest way to do that is by using the java
Collections classes that are designed for synchronization. Often the
easiest thing is indeed to use the synchronized Vector and Hashtable
clases For example, if all of your class's synchronized accessors are
ultimately calling through to add and remove elements from a Vector
stored in the user's session, you probably don't want to synchronize
the accessors themselves, unless there's something *in* the accessors
that needs to be synchronized.
You should also look into using Doug Lea's concurrent utils
package (http://gee.cs.oswego.edu/dl/). Lea wrote the book on
multithreaded programming in java (see URL below), so his library
is probably better than anything you'll come up with on your own,
in the limited time you have to work on it.
> Unlike the J2EE tier (where the 'synchronized' keyword is even
> forbidden), the *web container* doesn't care about thread safety at
> all. It's entirely the programmer's responsibility to take care of
> all threading issues. Furthermore, this has nothing to do with
> Sessions, too. In fact, the opposite is true. Even within a session,
> a user can happily send multiple requests to the web tier which are
> then executed as different threads by the JSP rsp. servlet instance.
> [...]
> > What exactly do you mean by session could be accessed by two threads?
>
> Open another window in Explorer and see for yourself.
Typically most browsers will start up to 4 requests at the same
time, even without the user trying anything tricky with multiple
browser windows. If the user opens up two windows simultaneously, as
Christian notes, Bad Things will happen to unsynchronized persistent
data that both windows are manipulating.
> > > Also I've seen some poeple
> > > mention not to use Vector because it is "old". This is also not true,
> > > Vector can be useful and is not depricated at this time.
>
> In opposition to some opinions I've read here, I think using a
> Vector is quite state-of-art. Vector is the synchronized equiva-
> lent of ArrayList and a Collection now.
The primary criticism of Vector/Hashtable is that, because they
were introduced in the first few generations of Java, as Christian
notes below, people tend to use them all of the time, even when they
explicitly don't have to worry about multithreading. Since they *are*
synchronized, they are more heavy duty code, and consume more
resources. However, since all web programming my by definition be
multithreaded, I would suggest that you start by assuming you will
need Vector/Hashtable, and carefully examine the circumstances to see
if you can get away with using the unsynchronized collections.
> I don't see any advantages in using techniques to make an ArrayList
> behave as if it were a Vector. Considering "old": in the beginning,
> there were no Collection classes at all. There were only Vector,
> Hashtable and Java arrays. Then they introduced the Collection
> classes, first as an optional package, later being integrated into
> the J2SE core. Nowadays, a Vector is just another Collection type,
> and a thread-safe one. If you have a proper design and code against
> interfaces, you can easily exchange the specific implementa- tion by
> something better suited, a linked list implementation of the
> Collection interface, for example. This entirely depends on your
> concrete application. If doing so, and the Collection chosen is not
> thread-safe by itself, you may use static helper functions to deal
> with that issue, if necessary. If Vector or Hashtable suffice, just
> stick to these.
Good advice.
Steven J. Owens
[EMAIL PROTECTED]
"I'm going to make broad, sweeping generalizations and strong,
declarative statements, because otherwise I'll be here all night and
this document will be four times longer and much less fun to read.
Take it all with a grain of salt." - Me at http://darksleep.com
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
For digest: mailto [EMAIL PROTECTED] with body: "set JSP-INTEREST DIGEST".
Some relevant FAQs on JSP/Servlets can be found at:
http://archives.java.sun.com/jsp-interest.html
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.jsp
http://www.jguru.com/faq/index.jsp
http://www.jspinsider.com
