> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Richard Monson-Haefel
> This depends a lot on how your vendor handles clustering of MDBs. The
> specification you quoted is referring to the two different deployments
> (enterprise beans) that subscribe to the same destination. With queues,
> messages are only consumed once. So if you send a message to a
> queue, only one of the MDB deployments will be able to get it; the message
won't
> be available for other MDBs.
Actually, this issue is even more subtle (subtler?) than this. It
definitely depends on how your vendor distributes JMS. The finest grain you
can have is the case where the JMS "core" and its destinations can all live
on different nodes of the cluster. For example, the JMS service is on
machine A, destination "queue0" is on machine B and destination "topic1" is
on machine C.
Now, you can further complicate the picture by throwing failure recovery
into it. This can be addressed in two ways:
- only deploy one instance of the destination and handle failure and
recovery through smart stubs (and automatic redeployment of the failed
destination on a different node)
- deploy several instances of the destinations in the cluster but have only
one active and all the others dormant
And now the final step: how many redundant MDB's are deployed in a cluster?
If your MDB is clustered, you expect one instance of it to be present on
each node of the cluster.
The questions are:
- should all these instances be active? (i.e. connection opened, session
active and listeners installed)
- for all active instances listening to a Queue, how many should receive the
message?
- for all active instances listening to a Topic, how many should receive the
message?
Phew. I didn't think that just laying out the basic problem would take up
that much space. As you can guess, answering all these questions can be
quite lengthy, and once again, it all boils down to the choices your vendor
made, since basically all the behaviors described above are compliant with
the JMS and EJB specifications.
--
Cedric
===========================================================================
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".
