Cedric Beust wrote:
> > From: Richard Monson-Haefel [mailto:[EMAIL PROTECTED]]
>
> > This makes it difficult to bind a MDB to an outside JMS provider.
> > In other words, it would be very difficult to model this behavior when
> > using MDB from vendor A that subscribes to a JMS provider of vendor B.
> The MDB
> > vendor must have an intimate knowable and control of the JMS provider it
> > using if its going to realize the concept of a "single system image".
>
> Very true.
>
> Note that this (unfortunate) intimate knowledge between the JMS provider and
> the EJB container is already unavoidable: the specification states that if
> an MDB is transactional, then the message receipt must be part of the
> transaction. Since this is not the way JMS transactions are defined, JMS
> needs to know when it is delivering a message to a transactional MDB as
> opposed to a regular listener. In that case, it must begin (or resume) the
> transaction before the message is picked off the queue.
>
> Hence the impossibility to support external JMS providers while staying EJB
> compliant for an EJB 2.0 container.
>
If the JMS provider is XA compliant (supports 2PC) then the receive operation or
delivery of the message can be a part of the MDB's transaction, so that a
failure in that transaction will rollback delivery of the message.
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.jMiddleware.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".
