cxf-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christian Schneider (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CXF-180) JMS Transport support for transaction
Date Tue, 16 Dec 2008 07:24:46 GMT

    [ https://issues.apache.org/jira/browse/CXF-180?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12656906#action_12656906
] 

Christian Schneider commented on CXF-180:
-----------------------------------------

Hi Ron and Willem,

the SingleConnectionFactory is already used. So when you create a service with jms transport
in wsdl it makes sure you use only one connection. With the transactions it is probably a
little more difficult. You have to decide about that transaction manager and you have to proxy
your implementation. I think it could be solved without a spring config but I doubt people
will then still understand what is going on. 
And you will loose the option to keep the transactional context when calling other spring
beans from your implementation (at least I guess so).

Btw. why do you want to have the configuration in wsdl only?

I see one more problem with jms transactions in general. How will we handle the case when
a transaction fails? Let´s imagine the implementation produces an exception for certain data.
So if I know jms transactions right the message will be put back into the queue and be delivered
to the implementation again. Which will throw an exception again ... I guess we will need
some kind of dead letter queue for these messages.

Another thing is how do we distinguish between exceptions that should roll back the transaction
and exceptions should create a fault response to the client?

> JMS Transport support for transaction
> -------------------------------------
>
>                 Key: CXF-180
>                 URL: https://issues.apache.org/jira/browse/CXF-180
>             Project: CXF
>          Issue Type: New Feature
>          Components: Transports
>    Affects Versions: 2.1
>            Reporter: Willem Jiang
>            Assignee: Willem Jiang
>
> Here are some points on the JMS Transport stuff:
> [ulhas]
> Currently JMS Session pool in Artix uses different Message Receiver
> acknowledgement mechanism than Celtix to provide Transaction support.
> (Celtix uses AUTO_ACKNOWLEDGEMENT) whereas Artix uses CLIENT_ACKNOWLEDGE
> for server side.
> [Willem]
> AUTO_ACKNOWLEDGMENT just make sure JMS broker client
> received the message, but not sure about the client had processed the message.
> If we want to support the Transaction in CXF, I think we need to change to
> CLIENT_ACKNOWLEDGE to make sure the message had been processed in
> message level.
> [ulhas]
> Second part of the transaction support is in current JMSServerTransport
> postDispatch code. This is the place where the server make sure that the
> message received can be processed and it is safe to send the
> Acknowledgement to JMS broker to remove the message from topic/queue and
> commit.
> [Willem]
> In current CXF JMS Transport implementation the transport just provide an channel
> to send and receive messages. All the message handling stuff need to play with the
> Stream. I think it is a good place in the OutputStream close method to send
> acknowledgment to JMS broker.
> So if we want to support local transaction in CXF JMS, we just need change the Session
> acknowledgment and the OutputStream close method. 

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message