"Tyler Jewell" <[EMAIL PROTECTED]> wrote:
> Since MDBs can be attached to a Topic or a Queue, do you foresee multiple
> MDBs attaching to the same Topic to process a single request from a client
> in parallel? This would be an alternative to having a client invoke
> multiple asynchronous requests (still saving time versus doing multiple
> synchronous requests on the client side). Essentially, if any parallel
> logic has to be performed on the server or by a client (such as a branch
in
> a workflow engine), do you recommend having a client invoking multiple
> asynchronous requests or attaching multiple MDBs to a single Topic?
The container should in principle be able to give you the parallel execution
you're asking for. For a single deployed MDB the container will likely have
a pool of instances at runtime, which will receive incoming messages. The
execution of the onMessage method on each instance will be serialized but
the overall experience will be concurrent execution of incoming messages.
To clarify this, let's say we have a topic with a single publisher and a
single subscriber. The publisher sends two messages "do this" and "do that".
The subscriber is a MDB and although only one subscriber has been deployed,
the container has a pool of instances and incoming messages are dispatched
to any idle instance. The result is that one instance will "do this" and
another instance will "do that" in parallel.
> What are the tradeoffs between using MDBs and JMS server-side message
> consumer pools? I think that using MDBs will decrease performance
slightly
> since you get the benefit of automatic transaction demarcation, support
for
> EJB security, and other EJB semantics. Besides performance, would there
be
> other reasons that you might select a JMS server-side message consumer
pool
> over an MDB?
JMS is intended to hook into a container by having JMS provide a connection
consumer and by having the container provide a server session pool. This
hook essentially allows the container do dispatch incoming messages to MDBs,
where JMS would normally dispatch incoming messages to consumers. The
container can even request that JMS loads up a session with multiple
messages before dispatch occurs.
So again, the container should in priciple be able to dispatch incoming
messages more efficiently than if you just have a pool of consumers. The
details of this will likely depend on the JMS implementation, e.g. depending
on how a JMS server connects to the target container you may be better off
with multiple consumers. Also, note that MDBs only support the Required and
NotSupported transaction attributes and limited security.
> Consider the following scenario: An MDB creates an EJB instance and
converts
> the remote interface to its Handle equivalent. The MDB then sends a
> response message to a Topic that contains the Handle of the newly created
> EJB. The Topic has many consumers, some of them remote clients. I know
> that this sounds ludicrous and is probably a very bad design, but I'm
trying
> to cover possible architecture ideas that may arise. Would this be a
> scenario where an MDB does some business processing; At the completion of
> the business processing, there is a large amount of in-memory data that a
> variety of clients might like to view. Instead of sending the data back
to
> all interested clients via a JMS Topic message, might it be possible for a
> bean to create a stateful Session Bean and send the remote Handle to the
> Topic instead of the data? Granted, the clients will have to synchronize
> access to the stateful bean, but they could access the data at their
leisure
> without using an entity bean. Ok, let me know if I'm off my rocker, but
if
> I'm crazy enough to think up this scenario, I'm sure someone else might
be,
> too.
In my opinion this is not necessarily bad design; I'd prefer sending smaller
messages that contains a reference to larger chunks of data. This is of
course unless all consumers absolutely needs this data in which case the
buffering capablities of a messaging system comes in handy. A useful thing
to do is to put some information about the data into the message header such
that clients can more easily filter out messages.
Best regards,
Bjarne.
===========================================================================
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".
