Executing an EJB on a separate thread

[James Davidson]

First, let be clear that I want to execute an EJB on a separate thread, not perform threading within an EJB as I know that violates the spec.

I have a web page that makes a number of relatively expensive EJB calls. Each page requires from 2 to ? calls, each typically from 3 to 7 seconds each. As you can see, this adds up. Some of the data I do not require right away so I have begun creating separate threads to execute some of the EJBs in the background and return their results.

I have actually gotten this to work by:

1. Caching the Home interface.
2. Spinning off a separate thread for each EJB.
3. Creating a Remote object in the thread.
4. Invoking the desired EJB method.
5. Updating the view object for the page from the EJB result.

This allows we to display a page to the user relatively quickly as opposed to waiting from 20 to 30 seconds for all the EJBs to complete.

Are there any potential problems associated with executing an EJB on a separate thread? Everything seems to work as expect it to but I am somewhat leery as I do pretend to be an EJB expert.

Any comments regarding my approach would be appreciated. Thanks!

[Scott Selikoff]

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.

[Jimmy Clark]

I have a web page that makes a number of relatively expensive EJB calls.

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?

Are there any potential problems associated with executing an EJB on a separate thread?

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"?

[James Davison]

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.

[Jimmy Clark]

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?

[James Davison]

Thanks for your responses but I have now discovered the WorkManager API which I believe will do what I want to do within a Java EE environment.

But to answer your questions:

What does the first sentence above mean?

Sorry. It should have read: The code that is creating the threads IS on the server.

What code is creating the threads? Or, where do you think you can put code to create threads that will have EJB calls?

A class invoked by the model class (on the server) used to create the view required by a page.

Will you be calling a Session EJB or an Entity EJB?

Stateless Session EJBs.

Why do you need to create an EJB to get data from the database for display on a web page?

I have no choice. These are vendor-supplied EJBs to interact with their product (on a mainframe). I have no direct access to the data.