[
https://issues.apache.org/activemq/browse/SM-1726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=48259#action_48259
]
Freeman Fang commented on SM-1726:
----------------------------------
Hi Ron,
You said "recognize that the CXF JMS transport is transaction-enabled and send
a transactional exchange to the NMR accordingly", do you mean if we detect the
cxf bc consumer over jms transport is transaction-enabled (actually it's cxf
over jms server side is transaction-enabled), we should do something in
CxfBcConsumer like
TransactionManager tm = (TransactionManager)
getContext().getTransactionManager();
tm.begin();
InOut me = createInOut();
getContext().getDeliveryChannel().sendSync(me);
// retrieve the out message
me.setStatus(ExchangeStatus.DONE);
getContext().getDeliveryChannel().send(me);
tm.commit();
This is my first understanding for your description and honestly I agree with
it for my first thought.
But after going through the code in servicemix-jms consumer (which is also used
as transaction component)and realizing how cxf jms server transaction works, I
believe we needn't do things like tm.begin()/tm.commit() in CxfBcConsumer.
Let's say the work flow is
external client <=======> cxf bc consumer over jms with transaction enabled
<===========> whatever in the JBI container
The cxf bc consumer(which actually is a kind of cxf server) itself will
determine to rollback and redeliver if get some exception, all rollback/commit
stuff should be done by cxf jms server it self.
That's also the way how servicemix-jms component do the transaction, what we
need is just set the transactionManager and needn't do things like
tm.begin()/tm.commit() explicitly.
IMO, what we need do is
1. inject the transactionManager which is used by the jbi container to cxf
JMSDestination.
2. when we found the cxf bc consumer is transaction enabled, we need always
use sendSync() to send out message to the NMR, since as Willem point,
only sync is supported in case of transaction enabled.
3. we also need consider how to filter the expected exception(like some fault
defined in the wsdl) to avoid causing rollback.
Currently it specified in TranscationProxyFactoryBean(the wrapper of the
implementator) in cxf-180 test, but for smx, the cxf bc consumer may connect
anything inside JBI container, which means we have no concept of implementor at
all.
What do you think?
Freeman
> Develop test case to demonstrate and verify that smx-cxf-bc consumer endpoint
> with transactional JMS transport sends transactional exchange correctly
> -----------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: SM-1726
> URL: https://issues.apache.org/activemq/browse/SM-1726
> Project: ServiceMix
> Issue Type: Improvement
> Components: servicemix-cxf-bc
> Affects Versions: servicemix-cxf-bc-2008.01
> Reporter: Ron Gavlin
> Assignee: Freeman Fang
>
> The CXF JMS transport was recently re-written to be based on Spring JMS.
> Assuming that issue http://issues.apache.org/jira/browse/CXF-180 is now
> resolved, it should be possible for the smx-cxf-bc consumer to be configured
> with a transactional JMS transport. In this situation, the smx-cxf-bc
> consumer must recognize that the CXF JMS transport is transaction-enabled and
> send a transactional exchange to the NMR accordingly.
> A test case should be written to demonstrate this functionality and ensure
> that it is working as designed.
> It would be useful to demonstrate this with both:
> 1. a wsdl-based configuration <jms:server transactional="true"/>
> 2. a cxfbc:features-based configuration (see SM-1725)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
