I have a web page that makes a number of relatively expensive EJB calls.
Are there any potential problems associated with executing an EJB on a separate thread?
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.
Have you tried Message Driven Beans? Its one of the J2EE ways to create a thread that is supported by the spec.
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?
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.
What does the first sentence above mean?
What code is creating the threads? Or, where do you think you can put code to create threads that will have EJB calls?
Will you be calling a Session EJB or an Entity EJB?
Why do you need to create an EJB to get data from the database for display on a web page?