It violates the spec for a good reason, you're breaking security, risking breaking transactions, and otherwise a program that isn't really an EJB.
Would please clarify? How does this break security? Why is it not an EJB? As far as breaking transactions, the stateless session EJBs in question are used to retrieve data from a mainframe only. No updates are performed.
Have you tried Message Driven Beans? Its one of the J2EE ways to create a thread that is supported by the spec.
This may be a better option but I am reluctant to do this. The EJBs in question are provided by a third-party vendor to access data on a mainframe and the only reason EJBs are used in this particular application. And I (a consultant who contract expires at year-end) am reluctant to introduce more complexity into this application because the level of
Java knowledge on my team is really low. The other team members are all former mainframers who are capable of creating syntactically correct code but have yet to grasp fundamental concepts of object-oriented programming. Simply attempting to spin these expensive tasks off into a separate thread is an advanced concept for them.
Please explain this a little. How is a "web page" making numerous calls to an EJB? What on the page is making the calls? What triggers each call to a EJB?
Okay, my explanation is perhaps not as precise as I thought. The web pages themselves do not make the actual calls but a number of EJBs are required to retrieve all the data to display the pages because the vendor API is, shall we say, "clunky" and several calls are required to retrieve all the data the users wish to see on the page. These calls are initiated by a model class on the server that pulls data together into a view used to create the page.
Firstly, you are not executing an EJB. You are calling a method of the EJB's Remote interface. Where is the code that is creating the threads? What creates the threads? the "web page"?
The code that is creating the threads on the server. Because there are several web pages that are displayed in sequence, I can often anticipate at least some of the data that will be required for a subsequent page. And that is the reason I would to spin some of these tasks, e.g. EJB calls, off in a separate thread. While I am creating the view object for one page, I would like to create a thread the proactively retrieves data I will likely need for the next page to minimize response time once the next page is requested.