It all comes down to the specification of J2EE. The reason is because the J2EE container takes care of the lifecycle of ejb. As a result, EJB does not support multi-threading. If you require mulitthreading in your application, I think you should not be looking at J2EE. I assume you needed mulitthreading because you are coding some server socket, and this is another thing J2EE forbids.
Joined: Mar 26, 2002
I had wanted to speed up some code that looked like this:
run query 1 run query 2 run query 3
use results from all queries to do something useful
The pattern above requires that we pay for bandwidth latency for each query we run. I was able to dramatically reduce the time to run all queries by running all queries in background threads and waiting for all to finish. This would have consumed more connections from our pool, but the increase in speed might have made it a reasonable trade off.
So if EJB doesn't support multithreading, am I stuck with the design pattern of running each query in order?
You must not spawn threads from within the EJB container to run the queries. But if your queries originate from outside the EJB container, then by all means submit them in separate threads. If you do it this way, the EJB container will probably run each query in a separate thread.
SCJP 1.4, SCWCD 1.3, SCBCD 1.3
Joined: Mar 28, 2005
Hi, Dave. Yes with EJB you can not do mulit-threading, but it does not mean you have to execute each of them in order. I think you are talking about asynchronous processing of the 3 queries. I think what you can do is have your stateless session beans fires 3 JMS messages to the message queue, and you have to code one message bean to handle each query. If you do this, you can have simultaneous processing of 3 queries. However, it is left to you as an problem to solve how to collect the results from the 3 queries.
Maybe for your particular problem, you better not use EJB. [ June 14, 2005: Message edited by: Jeremy Hsu ]