We are trying to migrate a heavily threaded Java app to an EJB environment. The current app has an applet submit a request to the server that entails accessing a number of enterprise resources that each can take a significant amount of time to execute. Therefore, it will kick of a thread for each request, block until they are all done, and then assemble the data, and ship it back to the client. Since EJB does not allow a bean to kick off a thread, and we are stuck with iPlanet which has no Message Beans, does anyone have any bright ideas? Serializing these requests would be an excessive performance hit, and moving the multithreaded business logic outside the EJB container would defeat the very purpose of having biz logic reside in the container.
For example, assume we have three requests from three different sources each taking 2 minutes. If they execute in parallel, we can get a response time of 2 minutes. If we serialize, it'll be 6 minutes which is absolutely unacceptable for our floor traders!
- EJB and multithreading by Rich Boyde on June 04 2001 10:36 EDT
- EJB and multithreading by Aditya Anand on June 05 2001 10:39 EDT
- EJB and multithreading by Tom Cook on June 06 2001 02:20 EDT
The spec says you should not use threads with in the EJB container, that does not mean you can not have a threaded application access the EJB container. Simply use your applet to call the server as you had done before, the server splits into X threads (3 in your example case), those three threads then make calls to the EJB container to perform the "Business Logic" and return results to the server, the servers sole purpose in life would be to combine the results and return to the applet. You could utilize a servlet or jsp instead of applets if you so desired.
applet to call the server as you had done before
We've thought of this option, but as I mentioned we want to dispense altogether with this server layer. We'd like all business logic, especially the the aggregation of the 3 threads, to reside in an EJB. This aggregation is the very core of the business. Also, a very important concern is that this whole configuration must be clustered. If we have an auxiliary RMI server (or even servlet) living outside the EJB container, it would greatly complicate things. Again, it seems that EJB isn't capable of handling high performance real life situations.
I'm using iAS too and have a similar scenario at hands... only at a much larger scale...
ship off messages from a application-helper class (which would probably be invoked by your request dispatcher) to a pub-sub topic and let message-listeners (to these messages) intereact with business objects to generate responce. These would drop the messages off to the application-helper, which inturn would compose the final responce....
To better understand this look at the ServiceActivator Pattern...
The second way is to have the application-helper spawn multiple threads, a total nobrainer... but dirty as hell...
I would not use it myself given the scenario... I'm sure you have not just one instance of the given scenario...
a good thing about service activator is that it lets you process parts of a request outside the iPlanet Appserver if needed....
Of cource you need a message server.... I guess you have it... if not it's pretty easy to persuade ppl to get it... good one's are not really expensive.... good avenue for application partitioning as well :)
hope this helps
My advice is get a server with MDB - it is clearly the solution to what you are trying to do. I know you say you are stuck with iPlanet, but Sun's website claims iPlanet is J2EE certified - surely includes MDB? Or maybe not until EJB 2.0. Anyway, if iPlanet won't do what you NEED then I suggest you get unstuck from it ASAP.
iPlanet sells the MDB solution separately... JMQ, despite the reviews on this site, since sp2 it's not so bad... functionally... you've got to stay off there GUI interfaces though... cmd-line is the way to go. But if sun wants to go anywhere with iPlanet they have to make it more newbie friendly