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
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.
Joined: Jul 18, 2002
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 ]
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.188.8.131.52 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."
James Carman, President<br />Carman Consulting, Inc.
Joined: Jul 18, 2002
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:  Add a static Map to hold thread handles  Add a public static getThread method  Add a private setStatus method  Add a public getStatus method This should do the trick