Randy:
One approach that might work is to endow all your beans with
a public async message interface & an internal queue &
to have them communicate with one another via
that interface (e.g put(MsgClass msg)). Thus the coordinate
would send each worker a Serializable command message, causing an
associated thread to be assigned by the EJB server, and then "wait" for
reply messages from each, counting down as required. This wait is not
truly a wait, as the coordinator would simply return from the invoking
call.
Re-entrancy might be an issue, as workers attempt to
respond in parallel, or while the coordinator is still
executing. If the bean is defined as a re-entrant entity
bean, re-entrancy would be allowed to occur (instead of
causing an exception) & could be detected and the message queued
for subsequent processing by the thread that currently "owns"
the bean, when it completes the processing of the current event.
The thread that deposits the message would simply
return. When all is done a callback to the request initiator
could be invoked over RMI, using the same message interface if
need be.
BTW: This type of scenario would be trivially
handled had async messaging served as the foundation for EJB
instead of RPC.
Regards, Arthur Allen
Get Your Private, Free Email at http://www.hotmail.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".
