Forums Register Login

HttpSession methods thread-safe?

+Pie Number of slices to send: Send
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
+Pie Number of slices to send: Send
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.
+Pie Number of slices to send: Send
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?

:roll:
[ August 30, 2002: Message edited by: Neil Laurance ]
+Pie Number of slices to send: Send
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.2.3.3.3 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
thread.
References to the request and response objects must not be given to objects
executing in other threads as the resulting behavior may be nondeterministic."
+Pie Number of slices to send: Send
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
You don't like waffles? Well, do you like this tiny ad?
a bit of art, as a gift, that will fit in a stocking
https://gardener-gift.com


reply
reply
This thread has been viewed 1036 times.
Similar Threads
Are Session attributes thread safe?
How to read XML Data in action class..
threadsafe objects
Is pageContext.setAttribute() Thread-safe?
vetor thread safe?
More...

All times above are in ranch (not your local) time.
The current ranch time is
Mar 29, 2024 07:30:54.