Cedric Beust wrote:
>
> > From: Evan Ireland [mailto:[EMAIL PROTECTED]]
>
> > No. JMS shouldn't deliver the same message twice (or at least if
> > a message is delivered twice in unusual circumstances the JMSRedelivered
> > flag should be correctly set).
>
> Agreed, but I think we're misunderstanding each other. I'll be more
> specific.
>
> Consider the two following cases:
>
> 1) Cluster made of nodes A and B. MDB M1 listens to Topic "quotes" and is
> deployed on the cluster (meaning: the user actually only wants one instance
> of this MDB, but the server will deploy it on all the nodes for failure and
> recovery).
>
> 2) No cluster, just two machines A and B. MDB M2 deployed on A and M3
> deployed on B, both listening to the Topic "quotes". This time, the user
> wants two different MDB's.
>
> The intuitive behavior expected if a message is published on the Topic
> "quotes" is:
>
> 1) only one instance of M1 receives the message, regardless fthe machine
> where it lives
> 2) both M2 and M3 receive the message
>
> Agreed so far?
Agreed.
> What I'm saying is this: it is impossible to get this intuitive behavior
> without JMS and EJB sharing some intimate knowledge of each other. Remember
> that MDB's are supposed to be "real" JMS listeners, so JMS shouldn't deliver
> messages to them differently than to regular listeners.
I find your two sentences here contradictory. (I agree with the first,
and disagree with the second).
MDB's implement javax.jms.MessageListener, if that is what you mean by
a "real" JMS listener. There is no requirement that JMS be at all
actively involved in the delivery of messages to the MDB. This could
be seen as a function of the EJB container, as opposed to being seen
as a function of the JMS provider.
For example, an EJB container (to implement MDB) could do the following:
(1) receive a message from a JMS queue
(2) call MDB.onMessage()
(3) acknowledge the message (assuming onMessage did not fail)
As far as the JMS provider is concerned in this scenario, the MDB is
very different from a regular MessageListener (i.e. the container here
uses receive and acknowledge and the JMS MessageConsumer does not have
a listener set).
I wouldn't implement MDB's this way - this is just an example to point
out how an MDB is not necessarily a MessageListener in the way an
ordinary JMS client would use a MessageListener.
For a real example to show how JMS can treat MDB differently from
regular consumers, I will include a vendor-specific example.
<vendor>
Example: Sybase EAServer
Message Service is a CORBA component with built-in support for
client notification and component notification.
JMS is a wrapper over the Message Service client notification.
MDB is a wrapper over the Message Service component notification.
JMS provider does not know about MDB implementation.
MDB implementation does not know about JMS provider.
</vendor>
> > An MDB is not an ordinary JMS client.
>
> How so? To JMS, it certainly is a listener like any other.
See above.
> > I think that you are assuming that an MDB implementation has to use the
> > standard JMS interfaces (e.g. connection, session, or the 'application
> > server' JMS interfaces). It turns out that there is no such requirement,
> > which is a good thing
>
> Agreed. Actually, the current effort goes even further: not mandating the
> use of JMS as the underlying transport for MDB's (see for example the recent
> renaming of some MDB tags).
How do you reconcile this statement with your earlier one "Remember that MDB's
are supposed to be "real" JMS listeners, so JMS shouldn't deliver messages to
them differently than to regular listeners."
> > By the way, I do think this ia a great discussion thread! Let's
> > hope that we can get a wider discussion going.
>
> Agreed! Let's keep it up.
>
> --
> 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".
--
________________________________________________________________________________
Evan Ireland Sybase EAServer Engineering [EMAIL PROTECTED]
Wellington, New Zealand +64 4 934-5856
===========================================================================
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".
