Right Frank. So the invocation requests queue up at the helper class instead
of the bean. All we did was move the problem. This won't scale if there are
potentially many threads invoking on the bean at once. For the stateful
session bean case where we are only having one session context invoking on
the bean, this shouldn't be too bad. For the stateless bean case where many
threads may be invoking on the bean stub simultaneously, this will be a
serious performance bottleneck.
However, now that you have a helper class wrapper, you have a convenient
place to manage a pool of SB references from. Synchronization will only be
required on allocation and de-allocation from the pool which should be very
fast.
If anyone is interested, I have an object pooling goodie that does provides
a framework for generic thread safe object pooling. You simply implement a
factory that instantiates the thing you want pooled. It is not very
sophisticated (for example the pool size is fixed size). But it is probably
a decent starting point. Send me a note directly if interested...
Regards,
-Chris.
PS: I do open source too, just not trying to do all of j2ee!
> -----Original Message-----
> From: Frank Sauer [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, January 21, 2000 7:49 PM
> To: [EMAIL PROTECTED]
> Subject: Re: JMS and EJB:using a Helper class
>
> Sounds like a good idea, but wouldn't the invokation from
> the helper class to the session bean cause a re-entrancy
> problem? Unless it's a stateless bean and the event is handled
> by another instance from the pool. If it's a stateful bean,
> how would this work?
>
> Regards,
>
> Frank
>
> -----Original Message-----
> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rickard �berg
> Sent: Friday, January 21, 2000 4:25 AM
> To: [EMAIL PROTECTED]
> Subject: Re: JMS and EJB:using a Helper class
>
>
> Hey
>
> Proneel Guptan wrote:
> > To get around this restriction, we developed a helper class which
> > implements the MessageListener interface.
>
> Which is a good idea.
>
> > 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.
>
> Whoa.. now you're in trouble. The "wait" is not allowed (thread
> modification operations are a no-no), and your transaction is likely to
> time out. In essense you're using JMS in a synchronous way. Not a good
> idea.
>
> I would do something like this instead:
> * In the session bean you should indeed register a helper class with
> JMS, and the helper class should hold a reference to the session bean
> (get it in the session bean by doing ctx.getEJBObject()).
> * On onMessage your helper class should call the session bean, and
> preferably not the same method as did the register above. You can
> provide the message on the call
> * Your session bean may now process the message
>
> i.e. in SessionBean:
> public void listen()
> {
> Helper h = new Helper(ctx.getEJBObject());
> <register h with JMS somehow>
> }
>
> public void doStuff(Message m)
> {
> // Process the JMS message
> }
>
> and in Helper:
> ..
> MySession theBean;
> public Helper(MySession ms)
> {
> theBean = ms;
> }
>
> public void onMessage(Message m)
> {
> theBean.doStuff(m);
> }
> -----------
>
> I'm a newbie on JMS myself, but something like that should work well.
> And it only uses short transactions, whereas your solution involves one
> long transaction (=bad).
>
> HopeThisWorks(tm) :-)
>
> /Rickard
>
> --
> Rickard �berg
>
> @home: +46 13 177937
> Email: [EMAIL PROTECTED]
> http://www.dreambean.com
> Question reality
>
> ==========================================================================
> =
> 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".
>
> ==========================================================================
> =
> 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".
===========================================================================
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".
