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