wood burning stoves 2.0*
The moose likes EJB and other Java EE Technologies and the fly likes Threads in JEE Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » EJB and other Java EE Technologies
Bookmark "Threads in JEE" Watch "Threads in JEE" New topic
Author

Threads in JEE

Gene Dias
Greenhorn

Joined: Mar 15, 2012
Posts: 5
Hello, I am trying to determine the "approved" or best practices approach while in a JEE environment for doing the following: A client is on a web page and clicks a button. This starts a thread for monitoring a process, i.e. database activity, network, etc. This process will continue to run until the user clicks a button that tells the process to end. Other clients, and/or the same client then clicks a button to listen to the status being sent from that process which will continue to listen until the user clicks a button to stop listening.

I have already done the above by using a WebSocket to communicate with a servlet which gets an injected a singleton EJB that extends WebSocketApplication. But, this EJB is spawning the process thread to do the monitoring. Although it works and should continue to work since it is a singleton, it is not the "approved" way of doing it. Some suggestions I have reviewed discuss using JMS to spawn the thread, but, unless I am misunderstanding something, this doesn't solve anything since a Message Driven Bean isn't supposed to spawn a thread either. So, what is the approved/best practices method of doing this? How does one start and stop a background process in a JEE environment? Again, the requirements are, only one process can be spawned, it must communicate to all WebSockets that register with the servlet, it must be able to die when told to (although that doesn't mean the server closes the sockets, since it could be started back up and would still communicate to all the previously registered clients).

Thanks.
Jaikiran Pai
Marshal

Joined: Jul 20, 2005
Posts: 9960
    
163

Gene Dias wrote:Some suggestions I have reviewed discuss using JMS to spawn the thread, but, unless I am misunderstanding something, this doesn't solve anything since a Message Driven Bean isn't supposed to spawn a thread either.

I think that suggestion was to push a message to a queue and the message would be picked up asynchronously by a MDB in a different thread. You won't have to spawn a thread from within a MDB since the MDB itself would be running in a different thread that the client which pushed the message to the queue. But I consider it a bit of a overhead to use JMS for the sake of what you are trying to achieve.

Java EE6 introduced @Asycnhronous invocations on EJBs http://docs.oracle.com/javaee/6/tutorial/doc/gkkqg.html which give you much more control and a simplified API for dealing with usecases like the one you have. Infact, Java EE6 which includes Servlet 3.0 support, even support asynchronous invocations from Servlets http://java.sun.com/developer/technicalArticles/JavaEE/JavaEE6Overview_Part2.html (check the "Asynchronous Processing in Servlet 3.0" section). See if either of these fits your usecase.



[My Blog] [JavaRanch Journal]
Gene Dias
Greenhorn

Joined: Mar 15, 2012
Posts: 5
Yes, the aysnchronous EJB will do just fine. Thank you. Actually, I implemented the asynchronous EJB, and not only did it work, the code was cleaner. So, no reason to cheat and spawn a thread. Thanks again.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Threads in JEE
 
Similar Threads
Processing lots of JMS messages
please answer this 128 questions for WLS. Urgently!
Java EE timer service and periodical jobs
How to use Threads in Servlets?
CMP and BMP