Yes, the request object is thread-safe. It is inherently in its nature. But the objects bound to the session can be potentially trouble spot. The only way( i think ) to screw a session is by opening multiple browser windows from the same client! In that situation, it is possible that multiple threads(from the same client) to access session state and to corrupt it. It is a non-likely scenario. But is can happen( most likely with IE, cause when you press ctrl+n, IE automatically creates request to the last visited page! Multiple ctrl+n will potentially create a problem).
Anyways, if you decide that's a risk you don't wanna take, couple of sollutions might come to mind :
1. Putting the service method synchronized(). Incredibly stupid sollution. That means that you'll permit one client to access your
servlet at a time. It means only one thread, so your problem can be solved. But the price you'll pay is way to high.
2. Putting portions of the code, that uses the troubeling code, synchronized. That won't solve the problem, cause it will do nothing to prevent other threads to access the
object. It will prevent the thread to lock the portion of the code, but it won't prevent other threads to use the troubeling object concurrently and inherently corrupt its state.
3. Whenever you use the troubeling object put a lock on the
object itself. That would ensure that only one thread at a time is tamprering with session data.
Well, that how I see it. Everyone with hers/his oppinions is welcomed.
Ice
[ April 24, 2006: Message edited by: Ice Penov ]