Greet the sun all,
Over the last couple of days, I have seen replies to various questions on EJB and
threading and these replies have all been the same: use JMS. However this is a poor
or misleading answer, given the current state of the EJB specification.
<soapbox>
For example:
I have an EJB bean (Foo.A) that goes about its merry business and somewhere it does
some processing that places a message on the queue. Now I have a message monitor that
implements a listener. This listener is informed that a message was placed on the
queue and it receives a copy of that message. Through various mechanisms, it
determines that EJB bean Foo.A should be informed.
However, because of the one-client/one-bean rule (talking stateful session bean (SSB)
here), the listener cannot inform Foo.A of this event. If it invoked, it would inform
Foo.B which would have no clue what to do because many times these messages are only
important in the context of the bean's currently held state.
The listener would have to route the notification to client and the client would have
to inform the Foo.A bean. Anybody want to give odds on how well such a round-robin
scheme would stand up to the rigors of a production distributed environment?
JMS has many wonderful uses in concert with EJB but it will not solve the problem
people currently have with EJB and threads and to state otherwise is unwise.
Developers are trying to solve real problems with EJB and many times, the solution is
the use of threads (or file I/O or some other EJB taboo). To say, "don't use threads
because of X" is not realistic. I will not sacrifice a workable solution on the alter
of some utopia like portability (I realize there are other reasons).
Deadlines have to be met and to say to someone to use a technology that is at least
six months before it sees the light of day in specification form (asychronous beans
and JMS integration for EJB 2.0) and a year before vendor implementation is ridiculous.
I understand a couple of vendors have integrated JMS. However, by the time you have
come to the problems that an integrated JMS would solve, the vendor has already been
chosen and the product purchased. Murphy's Law would dictate that the vendor is not
one that has implemented JMS.
</soapbox>
I guess what I am saying is that as a EJB developer community, we need to address the
BEST way to use threads within EJB until such time as the EJB products better support
JMS. I don't know if that means putting pressure on the vendors to have them come up
with a threading solution that will not break their container, put transactions at
risk, etc. I liked the idea of having vendors provide some type of thread pool that
an EJB bean could draw from, just like a DB connection pool.
Nothing like starting the morning with a little flame bait.
You may fire back when ready, Gridley!
Perry Hoekstra
Consultant
Talent Software Services
[EMAIL PROTECTED]
Get your FREE Email at http://mailcity.lycos.com
Get your PERSONALIZED START PAGE at http://my.lycos.com
===========================================================================
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".
