I apologize if this has been repeated, I have not seen the message in
the archives and I have had problems with my email.
>> Does anyone have experiences of MQSeries participating in EJB
>> transactions? For example if one transaction includes Entity Bean
updating
>> database table (JDBC) and a Entity or Session Bean inserting a
message
>> into MQSeries queue. Obviously I would like this whole transaction to
>> commit or rollback as one entity. I quess this would require
transactional
>> resource manager for MQSeries. Native MQSeries access (MQSeries
binding
>> for Java) supports syncpoints but that's not JTS compliant. Do I have
to
>> wait for JMS-version of MQSeries (when that one will be available?)?
>
>As you say, it is highly desireable that the putting and getting of
>messages to queues can be committed or backed out under syncpoint
control
>and this does indeed require that MQSeries be a transactional resource
>manager.
>
>In fact MQSeries is already a transactional resource manager supporting
the
>(pre-java) open standard for coordination of transactional resource
>managers, XA. Unfortunately, no EJB servers today are based on XA,
hence no
>there is currently no coordination between MQSeries and EJBs.
>
>This will be resolved soon, not sadly by EJB servers supporting XA,
because
>Sun is promoting the java-only JTA standard for achieving exactly the
same
>thing(*). Hence MQSeries will support JTA in a future release and will
>thereby be able to be coordinated by any JTA-compliant EJB server.
>
>You will not have to wait for MQSeries support of JMS - the two items
are
>unrelated.
JMS would not help you anyway. The JMS spec (8.5) states that:
It is important to note that a distributed transaction context does not
flow with
a message; and, the receipt of the message cannot be part of the same
transaction that produced the message. This is the fundamental
difference
between messaging and synchronized processing. Message producers and
consumers use an alternative approach to reliability that is built upon
a JMS
providers ability to supply a once-and-only-once message delivery
guarantee.
To reiterate, the act of producing and/or consuming messages in a
Session can
be transactional. The act of producing and consuming a specific message
across
different sessions cannot.
Therefore, I don't think that MQ's global unit of work could be
supported through JMS.
The best you could hope for is to have the message put as part of a
transaction that is
committed. The message get could be placed within a local unit of work
that would be
rolled back if an error occured or the offending message could be placed
on an error
queue.
Ian, any idea when MQ will support JTA?
Perry Hoekstra
[EMAIL PROTECTED]
--
Perry Hoekstra - [EMAIL PROTECTED]
Too often, we lose sight of life's simple pleasures......
Remember, when someone annoys you it takes 42 muscles in your face to
frown BUT it only takes 4 muscles to extend your arm and smack the
asshole upside the head.
===========================================================================
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".
