Paul Hodgetts wrote:
> The only way I know of to be compliant with current specs, is to
> implement the parallel processing outside the container. Either, as
> you suggest, have the client be multi-threaded and access distinct
> service beans,
(yuck)
> or have a single bean that calls out to an RMI object
> that implements the parallelism.
(can't do it; not standards-compliant, I don't think, according to views
on this list.)
> I think this second choice is still
> standards-compliant.
Don't think so.
> Both of these approaches aren't ideal. If the
> multi-threading is in the client, then we are forced to split out at
> least some of the processing algorithm out to the server. A separate
> RMI object adds the overhead of another remote call, plus we can't
> take advantage of cool app server features like load balancing and
> fail over.
Exactly.
[snip]
> The second option was to use JMS. JMS isn't integrated with EJB yet
> in a standard way, but WebLogic has a JMS implementation that seems to
> work well with EJBs in their container. We could send out a JMS
> message for each account to load (in your case for each precondition
> check) and have a JMS session pool process the messages in parallel.
> There's still the issue of how to coordinate the multiple responses
> that come back,
Exactly.
> because the main session bean thread needs to wait
> until all the responses come back before continuing (a "JMS join?").
Right. Note how complicated, overhead-intensive and just plain
irritating it is to do such a thing. JMS therefore should IMNSHO not be
the only solution for asynchrony in EJB.
> We didn't choose this approach because it just seemed really round-
> about to emit and catch messages just to do the parallelism. JMS
> seems better suited to true inter-component messaging. It's possible
> this approach could have some performance penalties from the JMS
> services as well (we didn't benchmark it, though).
You are right on.
> My opinion is that if the requirements really call for parallelism
> in the middleware (EJBs), right now under the current specs, our
> best option is to just go with the multi-threading.
Yep.
> We have to
> choose a container that lets us do it, and make sure we understand
> the container implementation well enough to properly exploit it. The
> threading design has to be well-behaved (thread pools, don't try to
> access context-dependent resources, join before returning from EJB
> calls, etc.). And our application design should encapsulate the
> threading parts so that moving to another container, or moving to
> some specified threading model in the future, doesn't cause massive
> rework. It can be done. It's not standards-compliant. It has some
> risks involved. That's my $0.02 USD.
Spot on. Note that it is relatively easy for a container to simply
expose a thread pool, which of course implies that it would be
relatively easy for such a thread pool to be made part of the standard
EJB specification.
Cheers,
Laird
===========================================================================
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".
