This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
I have a problem wherein a request should trigger a background task and return the response without waiting for the task to complete. I dont want to go for JMS for this asynchronous implementation. I am planning to implement this using threads. Are there any overheads of this? I am not passing any instance variables to the threads.
Using normal threads would be the way I'd want to do it too. But in my experience and from what I've read, there can be problems with the J2EE server's handling of those user threads. They always seem to recommend doing things the J2EE way (JMS, thread pools, etc)
i know that spawning threads in an ejb is frowned upon (violates the spec, yes?) because of problems with reentrance, but i have honestly not heard of a problem spawning a thread in a servlet, especially if you do your diligence to correctly manage it. having said that, maybe having your own threads could prevent the container from managing (i.e. destroying) the servlet class, but again, i do not know how often that becomes an issue, and if it's worth adding a whole new complex system (jms) because of that.
Joined: Jan 27, 2004
Originally posted by john guthrie: i know that spawning threads in an ejb is frowned upon (violates the spec, yes?) because of problems with reentrance, but i have honestly not heard of a problem spawning a thread in a servlet, especially if you do your diligence to correctly manage it.
For example, all versions of Weblogic thru the current 8.1 will not properly terminate daemon threads when the web-app / ear is shut down, such as during hot-redeployment of the app, leading to incremental leaks every time the app is redeployed without restarting the server. Problems do exist with threads in J2EE regardless of EJB or servlet or whatever. Having said that, I'd think it's a bug in the J2EE container in the first place, but nevertheless you have to be wary of creating threads.
Joined: Dec 19, 2003
Hey thanx for that. It does make sense. Anyways I found another workaround to this. Rather than creating a new thread, I am submitting two requests. One of the requests triggers the background process and updates the session once the job is done. I dont look forward to its response . Rather the other requests keeps polling the session. Once the session is updated it returns response. In this case I dont have to worry about managing threads and there overheads if any.