I am planning to implement this using threads.
Are there any overheads of this?
I am not passing any instance variables to the threads.
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.
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.
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.