Perry Hoekstra wrote:
> 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.
I agree.
> 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?
You've assumed a very simplistic message monitor, and I hope we'll get something
much better out of Sun's EJB/JMS integration work. There's no technical reason
why the message monitor should behave like a client of any bean it sends
notifications to. So if you assume that the message monitor can start new
instances and/or notify existing bean instances of the arrival of messages
without automatically being the client of the instances, then in your example,
Foo.A could be notified of the arrival of the reply message.
Of course, when using (synchronous) RMI between client and server the client
will have to poll Foo.A to find out about the reply. But by using asynchronous
communication also between client and EJB server we could avoid this ugliness
too.
For completeness, the message monitor should really be an event monitor and
should support other types of events as well, eg time, and container/JVM events.
> 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.
I agree. EJB needs a portable way to switch to a mode which allows creation and
suballocation of what I call "technical resources", things such as threads, file
handles and socket connections. Maybe the connector framework, when we get it,
can be used for this?
> 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).
As has been said before, the taboo is not "don't do it", it's "don't do it and
expect portability and by the way you may destroy the scaleability of your
application". And depending on your EJB server, you may have to, as Rickard has
said, use a different classloader to circumvent the prohibitions.
> ... snip ...
>
> 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.
The problem is that threads are not the only type of "technical resource". I
like my mode switch idea (above) better.
Ian McCallion
CICS Business Unit
IBM Hursley
[EMAIL PROTECTED]
Tel: ++44-1962-818065
Fax: ++44-1962-818069
===========================================================================
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".
