(Refer to my earlier post about a design issue involving a synchronous front-end using the services of an asynchronous back-end)


I have a session EJB called MessageHandler as defined below.

//SomeTibcoRVInterface dictates the implementation of
//the "onReply" method. This method is invoked by Tibco,
//when it is done processing the request.

class MessageHandler implements SomeTibcoRVInterface
{
//To use Tibco's services, a session has to be established
private TibcoRVSession rvSession =.....;

//Request a Tibco service. Pass
public sendMessage(message)
{
 rvSession.send(message,this);
 //Want to wait until Tibo has processed the request
 synchronized (this)
 {
  this.wait();
 }
 .....
 .....
 //return
}

//callback method
public onReply()
{
 //Wake up the blocked thread, which can now return to
 //the client of this class.
 synchronized (this)
 {
  this.notify();
 }
}
}

I need to wait until the reply comes back, ie., to provide synchronous request-reply behaviour with an asynchronous callback method, I am using thread synchronization between the two methods in this session EJB.

Are there any ill effects by using this kind of thread synchronization in an EJB?

Is there an alternative better approach to implement the above behaviour?

Any help is greatly appreciated.

Thanks.

Hi,

Here is my two cents worth. Blocking a container managed thread and doing thread sunchronization may not be a good idea. You may encounter strange behavior depending upon the J2EE vendor. The EJB spec also prohibits this kind of explicit thread management.

Here is one solution. I would have a thread calling TIBCO. But the the session ejb thread will be decoupled from it through a in memory message queue. Your session bean will simply insert a message in the queue and return to the client. The TIBCO thread will pick up the message, call TIBCO. When the call back is called, the response will be stored somewhere. The implication is that the client will have to make another call to fetch the reply. Essentially, one synchronous client call has been split into two synchronous calls with an wait period between the two calls. The blocking is happening in the client thread inside the servlet engine.

Pranab

On the assumption that the servlet engine is another "container" then this suggestion has the same problem. A servlet thread is also a container managed thread. It's a sevlet container rather than an EJB container but it's still a container managed thread.

The EJB spec is rather vague and unhelpful when it comes to threads, so I would suggest you just test the hell out of it and make sure it works on all target platforms with realistic load conditions.

Chz

Tony

Tony,
Unlike the EJB Container, I don't think the servlet container has any restrictions on spawning off new threads from within a servlet. So, I think the servlet container & the ejb container are two different animals. One does not have any thread restrictions while the other explicitly discourages use of threads.

Could you point me to any resources which point to problems in spawning threads in a servlet?
Thanks,
--Das

Hi
am posting this message to u coz u seem to have worked on TIBCO. can u suggest me how do i go abt learning everything abt TIBCO.

prompt reply is appreciated.