my dog learned polymorphism
The moose likes Servlets and the fly likes HttpSession methods thread-safe? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login

Win a copy of Java Interview Guide this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Java » Servlets
Bookmark "HttpSession methods thread-safe?" Watch "HttpSession methods thread-safe?" New topic

HttpSession methods thread-safe?

Neil Laurance
Ranch Hand

Joined: Jul 18, 2002
Posts: 183
Hi there. I'm developing a fairly complicated servlet that sends a page back to the browser immediately, and spawns a Thread to generate content offline. The page sent back initially contains a 'meta' flag to cause the page to be refreshed periodically, looking for the offline content generation to have completed. At the moment, I am using session.getAttribute and session.setAttribute in both threads, and was wondering if this is safe?
Any advice would be greatly appreciated
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 17423

In the case where only one thread writes an atomic object and only one thread reads it, there's not much of an issue. Advanced thread-control issues come into play only where there's a possibility of the value being referenced is in the middle of being updated.
However, you haven't said how you're going to connect the querent with its thread.
There's two ways to do this, each with its own benefits and drawbacks.
1. You can run a single "engine" thread, have the servlet post work to it and a later servlet invocation query/get the results.
2. Each query can spawn its own thread. No queueing required, but each querent has to be able to tie back to its proper thread.
In either case, you'll need to anchor the thread (or threads) so it will keep running - and be referencible - after the servlet's process method has returned.
The Vector and Hashtable utility classes are synchronized, so they're good choices for that sort of work.

An IDE is no substitute for an Intelligent Developer.
Neil Laurance
Ranch Hand

Joined: Jul 18, 2002
Posts: 183
After some further investigation:
I'm using something similar to the 2nd technique, where a class level Map holds threads keyed by their toString values. I then make post back a page with a hidden form which requeries itself to see if the content is yet ready. It works quite well, altought I need to ensure the thread can work with a valid (copy/handle) of the original HttpServletRequest instance. Something like:

A more elegant way anyone?

[ August 30, 2002: Message edited by: Neil Laurance ]
James Carman
Ranch Hand

Joined: Feb 20, 2001
Posts: 580
Not a good idea to use request objects outside of the scope of the request handling thread! Some application servers use a pool of request objects instead of creating a new one for each HTTP request that comes in. Check out the servlet specification...
"SRV. Thread Safety
Implementations of the request and response objects are not guaranteed to be thread
safe. This means that they should only be used within the scope of the request handling
References to the request and response objects must not be given to objects
executing in other threads as the resulting behavior may be nondeterministic."

James Carman, President<br />Carman Consulting, Inc.
Neil Laurance
Ranch Hand

Joined: Jul 18, 2002
Posts: 183
Yup. Thanks for the advice. After further testing, I discovered this myself. I got around this my copying the parts of the request I was really interested in (namely the parameters, and their values) during the Offline thread constructor, before the session handle gets reused. Thanks for all the ideas - I now have a bit more information to move from my prototype to a working solution. Since the servlet I wish to monitor is already a thread in its own right, I think all I need do is:
[1] Add a static Map to hold thread handles
[2] Add a public static getThread method
[3] Add a private setStatus method
[4] Add a public getStatus method
This should do the trick
I agree. Here's the link:
subject: HttpSession methods thread-safe?
It's not a secret anymore!