Is it ok to store a Thread object in a session or application attribute?

I'm not sure if I'm on the right track, but I have previously created a Thread and stored it in the current session to be able to use it in other Servlets.

When a user logs in, I need a Thread that will periodically poll a webservices server and retrieve updates. When the user logs out I want to stop/pause the Thread.

If I create the Thread when the user logs in, I need a reference to this Thread if I want to pause it when the user is logged out, and then start it again when they login.

What is the best and correct way to go about this? Should I monitor the session from inside the Thread and if the user has logged out, have the thread return in order to end the Thread?

Then next time the user logs in, I can create a new background Thread?

***I need the thread to run in the background and poll a web services server for updates which I use to update my database. It may poll once every 5 minutes.

I don't want it to be polling all the time, hence why I was trying to control it based on the user being logged in or not... I was setting the boolean running to false when they log out in order to stop the thread. Because the thread was stored in the application context, I could then set running to true when they logged back in.

What about a Thread to run in t开发者_Go百科he background and check something, for example that your internet is up?

I know how to create the Thread, but I'm confused about how to terminate it, since it needs to be continually running in the background.

Am I using threads for the wrong thing? should I be using something else?

Thanks again, hopefully this is a better explanation...

Since servlets themselves will be instantiated multiple times at the same time, creating even more threads is not a wise idea. You will run into problems if you decide to cluster your application one day across multiple machines because of serialization issues, so you're locking yourself at the beginning.

Besides, it seems your problem can be done using AJAX pooling from client side. Why pool a webservices server and retrieve updates if you can't show them to your client without them refreshing the entire page?

Think of this scenario: if a user sessions lasts for 30 minutes, and a user doesn't log out, but just closes the browser window: you won't know that this happened, and you would pool for next 30 minutes that webservice, which is a waste of resources.

A Thread is not serializable, so storing it in a session is likely to be problematic.

Also, stopping or pausing a thread can be problematic unless you code the thread's Runnable to periodically check to see if it has been paused / stopped and act accordingly. (The Thread.stop() and Thread.pause() methods are deprecated and you should avoid using them. They can potentially destabilize your JVM.)

Even if you address the above issues, there are a host of resource management issues to be addressed.

I'm not sure if I'm on the right track

In short, you are not, IMO.

You have not explained why you need to associate a thread with each session, or what these threads are intended for. If you did, you would get some good suggestions for alternative approaches that (largely) avoid the problems above.

FOLLOWUP

I wasn't using .stop and .pause.

Good.

i was using a boolean "runnable" to control the thread.

That's one alternative. I prefer to use the Thread.interrupt() mechanism, because it allows you to interrupt a thread that is blocked on an I/O operation or in a wait(...) call to stop.

What if you are polling a device, and need to access returned data? What is the best approach?

Probably, the best approach is to create a thread or thread pool in servlet initialization that is responsible for polling the device(s). If you need to save the returned data so that it can be accessed in a subsequent HTTP request, put it into (say) a queue that the request controller can access. You may need some infrastructure to remove uncollected data objects from the queue after a certain period, etc.

You really shouldn't be creating Threads inside containers at all. What's it for?

And if it's for use by other servlets it's more likely to belong in the application attributes, not the session attributes, isn't it? or are you really creating a thread per user? which you really don't want to do.

I can see, that there may be valid reasons to do the polling server side in a background thread: For example it may take longer than a user wants to wait for the answer of a request. And there is the issue that some anti-discrimination laws (to be more precise the guidelines on how to interpret those laws) deny the use of JavaScript, so no Ajax.

So if there is really no other way, I suggest to create one thread (or a very small thread pool) in Servlet.init(). This single (or small number of threads) should do the polling for all active users. In web.xml you can define a session listener so you can keep track of opened and closed/expired sessions.

Make sure to signal in Servlet.destroy() that the thread(s) should exist.

To define a session live cycle listener add this in web.xml:

<listener>
    <listener-class>
        com.example.SessionListener
    </listener-class>
</listener>

And then remember the open sessions, so that you can iterate over them in the background thread.

public class SessionListener implements HttpSessionListener {
    private Set<HttpSession> sessions = Collections.synchronizedCollections(
         new HashSet<HttpSession>());

    public void sessionCreated(HttpSessionEvent sessionEvent) {
        HttpSession session = sessionEvent.getSession();
        sessions.add(session;
    }

    public synchronized void sessionDestroyed(HttpSessionEvent sessionEvent) {
        HttpSession session = sessionEvent.getSession();
        sessions.remove(session);
    }
}