I have a scenario in which the results of various students are generated from within one ejb call by looping over the student list. I was thinking of creating threads for processing each student using executorService within a ejb call. Currently i just look up my ejb once.
-
I'm not sure what you are asking for--can you elaborate? – David Apr 15 '15 at 17:01
-
What I mean is there is some independ work to be done for each student in a class in an ejb method..i want to do that work parralely for each of this students usung threads..Am i clear now? Or u need more information? – Abhinav Walia Apr 15 '15 at 17:58
2 Answers
i think this post should answer your question
in general an EJB should not spawn new threads or do 'handcrafted' asynchronous execution.
-
Actually, that *rule* was supposed to hold for all user code in the container, not just EJB. But at the time this was written in the spec "EJB" was seen as the underlying (or overarching, depending on your pov) technology for the entire server. – Arjan Tijms Apr 16 '15 at 10:53
In EE 7+ servers, you should just use JSR 236, which let's your application have access to executors/pools that are managed by the application server.
Otherwise, in theory, the EJB spec does not allow EJBs to create their own ExecutorService, which would create/manage its own threads:
The enterprise bean must not attempt to manage threads. The enterprise bean must not attempt to start, stop, suspend, or resume a thread, or to change a thread’s priority or name. The enterprise bean must not attempt to manage thread groups.
These functions are reserved for the EJB container. Allowing the enterprise bean to manage threads would decrease the container's ability to properly manage the runtime environment.
In practice, it might work if you have complete control over the server running your application (you know which other applications are running and how many threads/pools they're creating in order to avoid overloading the system), and you limit the actions taken in those threads (for example, java:comp
lookups won't work, transactional behavior might be limited, etc.).

- 33,593
- 2
- 85
- 90