Re: JMS and EJB:using a Helper class

[Charlie Alfred]

Title: RE: JMS and EJB:using a Helper class

A couple of questions:

 

    1.  Is the SessionBean stateless or stateful?  As someone mentioned in an

         earlier thread, with stateful session beans you must concern yourself

         with the session timeout (which means that your bean handle might be

         invalidated by the EJB server).

 

    2.  Is there a reason that the SessionBean must wait for the JMS response?

         Could this be modeled as two asynchronous operations, instead?

         In other words, could your SessionBean method issue the JMS request

         (through a helper object) and return.  Then a MessageListener object

         handles the response, and invokes another method on the SessionBean.

 

    3.  Do you have a requirement to maintain transaction context over the

         JMS request/response?  If so, then the alternative suggested above

         is inadequate.  If this is indeed the case, then your options are likely

         to be determined by which scenario you fall under:

 

            a.  Your Session Bean is joining an in-progress transaction.

 

                 If this is the case, you might be S.O.L.  The EJB spec precludes

                 blocking operations like wait() from within an EJB.  While some

                 vendors might permit it, it's not portable.  Also, even if your vendor

                 supports it, you run the risk of causing deadlock by blocking all of

                 the available EJB worker threads.  Returning from the method

                 immediately after the JMS send is problematic, because the

                 transaction will continue (and may even commit before the JMS

                 reply is received).

 

            b.  Your Session Bean is starting the transaction, and the client

                 either doesn't need to know whether the transaction succeeded,

                 or support asynchronous notification (JMS or equivalent).

 

                 In this case, I'd let your SessionBean provide the interface to

                 the external client, and delegate the work to a helper class

                 that isn't as constrained by the EJB rules.  One way to do this

                 is an application of the Producer/Consumer design pattern:

 

                      >  implement a singleton class to manage a small pool of

                         worker threads, accept objects that implement the

                         Runnable interface, and adds them to a thread-safe

                         queue.

 

                     >  implement a second helper class that extends Thread.

                        Instances of this class are created and started by the

                        singleton.  Their run method simply blocks trying to

                        dequeue a Runnable, and when they get one, call its

                        run() method.

 

                    >  implement one or more helper classes that act as EJB

                       clients and coordinate the activities that must use JMS

                       and occur within the scope of the same transaction.

 

               Your SessionBean creates an instance of one of the EJB

               clients, queues it to the singleton coordinator, and returns.

 

               One of the thread-pool workers picks up the EJB client and

               invokes its run() method.  The EJB client calls a SessionBean

               method that does the first half of the transaction (up to the

               point where the JMS message is sent) and returns.  The EJB

               client then either does a synchronous receive on the JMS

               destination, or blocks waiting for the listener to process the

               response.  When the response arrives (or when you timeout),

               you perform the steps that remain.   

 

Hope this helps.

 

Charlie Alfred

Foliage Software Systems, Inc.

168 Middlesex Tpke

Burlington, MA 01803

 

-----Original Message-----
From: Douglas Nehring [mailto:[EMAIL PROTECTED]]
Sent: Friday, January 21, 2000 12:14 PM
Subject: Re: JMS and EJB:using a Helper class

Your scenario sounds familiar (we too are using JMS to publish back to a client).  Besides the spec issue, I found one other big problem-session timeouts (i.e the session EJB would be removed after a certain period of time).  I didn't play with timeout values after I realized that clients could potentially be connected indefinitely and setting a session timeout to infinity didn't seem like a good idea (don't even know if it can be done).

What I ended up doing was changing how we used the session EJB (I feel that this was for the better).  Pretty much I went KISS with the session EJB-it is used to just register and deregister a requesting client with the appropriate topic.  A "helper" object did the actual handling of the JMS stuff.  The session EJB just kicked off the creation of this helper or told it to shutdown.  As far as finding this "helper" to stop the JMS on a deregister, I used JNDI and that took care of having to have a reference hang around in the session EJB should that session be removed.  Is it the correct way to do it?  I'm not sure, but it solved the session timeout problem I was having

Doug Nehring
Meridian SL-100 Advanced Technology
Nortel Networks

"A well-written program is its own heaven;
a poorly-written program is its own hell."
--The Tao of Programming

-----Original Message-----
From: Proneel Guptan [mailto:[EMAIL PROTECTED]]
Sent: Thursday, January 20, 2000 7:09 PM
To: [EMAIL PROTECTED]
Subject: JMS and EJB:using a Helper class

Hi,

Being a newcomer to EJB (and this mailing list), I may be raising a
question that has already been threshed out previously. My apologies
if that is the case. I will re-search the archives for that discussion
(an initial look does not seem to have thrown up any previous threads
on this specific aspect of EJB-JMS integration).

The backbone of the application I am working on is essentially
asynchronous. JMS offers everything that is needed to do the job,
persistent messages, publish/subscribe model etc. We do however want
to present a synch interface to our clients in some cases and here
session beans seems to fit the bill. Our data model also seems to fit
nicely into the use of Entity beans.

In such a case, we would want our session bean to send out an asynch
message (on a Topic) and wait for a response. The problem is that we
have been discouraged (or forbidden?) from implementing the
MessageListener interface in our session bean, because the session bean
can be passivated any time and would not be invoked on the onMessage().
Or restating it as a concepts violation, the session bean in EJB1.1 is
a component for the "synchronous" domain and should not have
an asynch/callback nature applied on it.

To get around this restriction, we developed a helper class which
implements the MessageListener interface. The session bean does the
following:
synchronize(helperObject)
{
        helperObject.start(); // To switch on listening for messages in
                                 the JMS session in helperObject
        helperObject.wait(); // handle InterruptedException
        helperObject.stop(); // To switch off listening for messages in
                                 the JMS session in helperObject
        // process the message, which is stored in the helperObject
}

The helperObject meanwhile, in its onMessage() method:
synchronize(this)
{
        // process message received as input to onMessage()
        notifyAll();
}

Note that we ensure that the message listening is switched on only
when the session bean is actually waiting for a response.

This appears to work. But I am concerned that I may be missing
some subtle (or not so subtle) problems with such an implementation.
There doesn't seem to be much treatment on this topic either in books
or in the JMS/EJB specification (all they seem to say is that the issue
will be addressed in EJB2.0).

Are there any holes that I cant see?

Regards and Thanks,
Proneel.

===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST".  For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".