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