looking for design pattern for passing data to session bean

[Chris Johnston]

I have absolutely no idea how to put a subject on this post as it will take a paragraph just to sum it all up.

I have an application running the EJB container behind a single stateless session bean. Data gets passed to this bean from an outside client. Once the data is passed to the bean, the bean starts a processing sequence that performs various operations on the data, saving the data to the database after each operation is completed.

The session bean does not return anything and the client is not expecting a return value. As it stands right now, until the session bean method completes, the client is left blocked and not able to process anymore data.

Now for the question: Is there any simple way to pass data to the session bean in such a way that the client is not blocked until the session bean method finishes? What I would like is for the session bean to accept the data, return, and then pass that data off to begin the processing sequence. Is there anyway of doing this. Right now it accepts the data, starts the processing, waits until it ends and then returns.

Thanks for the help

Chris Johnston

[Valentin Tanase]

Hi Chris,

There is no way to make your SLSB processing the data asynchronously. Actually this is exactly the reason why J2EE 2.0 introduced the MDB. You might like considering to redesign your application. I can see two solutions at this time:

Change your clients to send JMS messages to a JMS destination and deploy an MDB to process the messages asynchronously. The MDB retrieves the messages one by one and calls a POJO (that replaces the SLSB - same logic though) for processing the messages.

Leave the clients as they are, but change the SLSB to act as a JMS producer and pack the client�s request in a JMS message that gets send to a JMS destination. Deploy the MDB again to process the message asynchronously.

Regards.

[Chris Johnston]

Thanks for the reply. There are actually two other solutions that will work as well:

1. Have the SLSB start a new thread that processes the data. This would allow the bean to return and the client to get back to doing what it was doing. However, I have been told on more then one occasion that starting my own threads inside an application server is not a good idea.

2. Make the client multi-threaded so that is can connect to more then one bean.

The more I think about this problem the appealing solution number 2 becomes. I want to stay away from JMS and true asynchronous method calls as much as possible. I am actually redesiging a system away from JMS because of the level of complexity introduced from messaging and JMS.

[david lightman]

I would definitely make the call asynchronous so the client is not blocking..
I would not use threading like you proposed but instead consider the advise of the MDB processing...

[Valentin Tanase]

1. Have the SLSB start a new thread that processes the data. This would allow the bean to return and the client to get back to doing what it was doing. However, I have been told on more then one occasion that starting my own threads inside an application server is not a good idea.

You can�t do that Chris. Your application might start a new thread, but not inside of an EJB. The EJB container was designed to associate one bean instance with exactly one execution thread. If your EJB calls Runnable.start() then another thread will start, the instance will go back to pool, and before the thread finishes, another client (or the same client) might get the same bean instance from the pool and start a new execution thread. At this point you�ll have two execution threads associated with the same bean instance; this will break your container. However there are other techniques for starting new threads (which as you said are not good practice), using startup classes, or using servlets with load on startup flag set to on. Asynchronous message processing was one of the reasons to employee these techniques, before EJB 2.0; but not many reasons to do it these days...

2. Make the client multi-threaded so that is can connect to more then one bean.

Back to your SLSB that processes the data and returns after a while. Following your design the client will start a new thread that calls the bean asynchronously. The client doesn�t wait anymore but the container will start a new transaction and will reserve a bean instance during that transaction. The problem here is that the client can do this all over again (since s/he doesn�t need to wait) and you might have more client requests than bean instances in the pool; the extra requests will be blocked until some of them become available. If no bean gets available before the transaction expires, then the container will throw a transaction time out exception. How will you handle this exception? If client A sends two asynchronous request R1 and R2, R1 succeeds but R2 fails, how can you notify the client that the first request succeeded and the second failed and not vice versa? Finally you might need to come up with a scenario to overcome these problems and you might end up implementing a more complex solution than using JMS.
Regards.

[Chris Johnston]

Hmmm... all very good points that I had not thought about. Thanks.

So I can't start new threads inside and I can't start new threads outside, that only leaves me with two options:

1. Use JMS and asynchronous method calls to get the data inside the system.

2. Figure out a way for the system to go out and get the information itself, thus removing the need for an outside client. This would involve accessing the filesystem though (and possibly other forms of IO). Any problems with opening various kinds of streams from within an EJB container?

However, if I go with option number 2, I no longer have anyway of triggering the session beans and am going to need a startup method that will start this whole process.

As you can tell, I really want to stay away from JMS.

There is a possible third option: that would be to move the entire thing from the ejb container into the web container and reintroduce threads, but also introduce a thread pool. Open a socket and pass the incoming information off to a thread to carry out the work. This would be very similar to how a standard web server works.

However, I already tried this solution and ran into a security policy problem. Anyone know how to set a security policy inside the web container to allow an object to listen to a socket?

So what do people think of these ideas?

[Valentin Tanase]

However, I already tried this solution and ran into a security policy problem. Anyone know how to set a security policy inside the web container to allow an object to listen to a socket?

Containers use the java SecurityManager class for adding extra security measures at file level. Hence your container uses a security policy file. Check your server�s startup scripts and look for an initialization parameter like this:

-Djava.security.policy="%WL_HOME%\server\lib\weblogic.policy

Open the policy file and add a line like this:

grant codeBase "file:/my_folder/my_file.bat" {
// allows anyone to listen on un-privileged ports
permission java.net.SocketPermission "localhost:1024-", "listen";
};

(Check online for SecurityManager and security policy files).
Regards.