Christian,

I assume only have txMgr or jmsTransactionManager, not both? I would love
to do that but camel only seems to support a Spring
PlatformTransactionManager and ActiveMQ expects a
javax.transaction.TransactionManager. Under the covers, as I understand
Aries, it is a single object that implements both interfaces.

There was a conversation a while back about refactoring Camel to be based
on the standard TransactionManager but I don't think it went anywhere as
far as I can see [1] (if I understand the conversation properly).

Chris

[1]
http://irclogs.dankulp.com/logs/irclogger_log/karaf?date=2012-01-25,Wed&text=on

On Tue, Apr 17, 2012 at 2:16 PM, Christian Müller <
christian.muel...@gmail.com> wrote:

> Could you try using only one transaction manager?
>
> Best,
> Christian
>
> On Tue, Apr 17, 2012 at 10:48 PM, Raul Kripalani <r...@fusesource.com
> >wrote:
>
> > It looks like you may not be using an XA-aware Pooled Connection Factory
> :D
> >
> > See
> >
> http://activemq.apache.org/maven/5.5.0/activemq-pool/apidocs/org/apache/activemq/pool/XaPooledConnectionFactory.html
> >
> > It may look catchy, but all the layers of the stack need to be
> > XA-aware, as XA requires a different behaviour when handling borrowing
> > and returning to the pool.
> >
> > Let me know if it works for you.
> >
> > Regards,
> > Raul.
> >
> > On 17 Apr 2012, at 18:31, Chris Geer <ch...@cxtsoftware.com> wrote:
> >
> > > Raul,
> > >
> > > Thanks for the information. I tried what you said and I think it did
> have
> > > some success with rolling back the transaction but it causes
> significant
> > > errors to be thrown during a success case. As I've written a sample to
> > > debug this issue I wanted you to have my latest code so we can be
> > > referencing the same thing if you're willing to take another look.
> > >
> > > README: http://pastebin.com/UWq3yk4c
> > > OSGI Implementation: http://pastebin.com/ifQTybn3
> > > OSGI Interface: http://pastebin.com/zEUP8jJJ
> > > Blueprint File: http://pastebin.com/sxBtxNCq
> > > Test Driver/Logger: http://pastebin.com/SDVFvjGm
> > > pom.xml: http://pastebin.com/kTXXaebV
> > >
> > > Part of the error I'm seeing is this (commit -> rollback)
> > >
> > > 10:12:52,624 | WARN  | 52 - timer://foo | PooledSession
> > > | 57 - org.apache.activemq.activemq-pool - 5.5.1 | Caught exception
> > trying
> > > rollback() when putting session back into the pool:
> > > javax.jms.TransactionInProgressException: Cannot rollback() inside an
> > > XASession
> > > javax.jms.TransactionInProgressException: Cannot rollback() inside an
> > > XASession
> > > at
> > >
> >
> org.apache.activemq.ActiveMQXASession.rollback(ActiveMQXASession.java:76)[60:org.apache.activemq.activemq-core:5.5.1]
> > > at
> > >
> >
> org.apache.activemq.pool.PooledSession.close(PooledSession.java:111)[57:org.apache.activemq.activemq-pool:5.5.1]
> > > at
> > >
> >
> org.apache.activemq.pool.XaConnectionPool$Synchronization.afterCompletion(XaConnectionPool.java:90)[57:org.apache.activemq.activemq-pool:5.5.1]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:540)[45:org.apache.aries.transaction.manager:0.3.0]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.afterCompletion(TransactionImpl.java:533)[45:org.apache.aries.transaction.manager:0.3.0]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionImpl.commit(TransactionImpl.java:329)[45:org.apache.aries.transaction.manager:0.3.0]
> > > at
> > >
> >
> org.apache.geronimo.transaction.manager.TransactionManagerImpl.commit(TransactionManagerImpl.java:252)[45:org.apache.aries.transaction.manager:0.3.0]
> > >
> > >
> > > Chris
> > >
> > > On Tue, Apr 17, 2012 at 9:44 AM, Raul Kripalani <r...@fusesource.com>
> > wrote:
> > >
> > >> I noticed several things in your config.
> > >>
> > >> 1) the JMS config should be inside the 'configuration' property of the
> > >> ActiveMQComponent:
> > >>
> > >> <!-- ActiveMQ JMS Configuration is defined as Transacted and leverages
> > XA
> > >> Transactions -->
> > >> <bean id="activemq"
> > >> class="org.apache.activemq.camel.component.ActiveMQComponent">
> > >>    <property name="configuration">
> > >>     <bean class="org.apache.camel.component.jms.JmsConfiguration">
> > >>        <property name="connectionFactory"
> > >> ref="pooledConnectionFactoryXa"/>
> > >>        <property name="transactionManager" ref="platformTxManager" />
> > >>        <property name="transacted" value="false"/>
> > >>        <property name="cacheLevelName" value="CACHE_NONE"/>
> > >>     </bean>
> > >>  </property>
> > >> </bean>
> > >>
> > >> 2) the 'transacted' property should be false as above, because you
> don't
> > >> want the component to manage the transactions locally. The enrolment
> of
> > >> resources and coordination of transaction will happen on the XA level.
> > >>
> > >> 3) you are missing the ActiveMQResourceManager, which needs an
> > injection of
> > >> a javax.transaction.TransactionManager, which in reality is the same
> as
> > the
> > >> PlatformTransactionManager, but you under a different interface
> > >>
> > >> See the following link for how your config should look like:
> > >>
> > >>
> >
> https://github.com/FuseByExample/camel-persistence-part2/blob/master/route-one-tx-manager/src/main/resources/META-INF/spring/springConfig.xml
> > >> .
> > >>
> > >> And of course, the route must be invoked from the same thread where
> the
> > >> transaction is being started, and you cannot use the SEDA component
> for
> > >> that. You must invoke it via a direct endpoint and I think
> > >> requestBodyAndHeader(), but I'm not sure about this last point.
> > >>
> > >> Regards,
> > >>
> > >> *Raúl Kripalani*
> > >> Principal Consultant | FuseSource Corp.
> > >> r...@fusesource.com | fusesource.com <http://www.fusesource.com/>
> > skype:
> > >> raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>,
> > >> @fusenews<http://twitter.com/fusenews>
> > >>
> > >> <http://twitter.com/fusenews>
> > >>
> > >> On 17 April 2012 16:53, Chris Geer <ch...@cxtsoftware.com> wrote:
> > >>
> > >>> Raul,
> > >>>
> > >>> I gave that a shot but it actually made the problem worse.
> > >>> ProducerTemplate.requestBodyAndHeader uses an InOut exchange pattern
> > but
> > >>> since I'm not sending responses it always fails (regardless of
> > >> transaction)
> > >>> with a timeout saying it didn't get a response. It also send the
> > message
> > >> to
> > >>> the topic even without the transaction being committed so it wouldn't
> > >> solve
> > >>> the transaction problem anyway.
> > >>>
> > >>> Chris
> > >>>
> > >>> On Tue, Apr 17, 2012 at 1:47 AM, Raul Kripalani <r...@fusesource.com
> >
> > >>> wrote:
> > >>>
> > >>>> Hi Chris!
> > >>>>
> > >>>> Transaction Managers bind transactions to threads, and a possible
> > cause
> > >>> for
> > >>>> your transaction getting lost is that your route is being called
> > >>>> asynchronously from another thread.
> > >>>>
> > >>>> This is because you are using ProducerTemplate.send...().
> > >>>>
> > >>>> Can you replace this with
> ProducerTemplate.requestBodyAndHeader(...),
> > >>> which
> > >>>> in theory should call the route synchronously in the same thread?
> > >>>>
> > >>>> Regards,
> > >>>>
> > >>>> *Raúl Kripalani*
> > >>>> Principal Consultant | FuseSource Corp.
> > >>>> r...@fusesource.com | fusesource.com <http://www.fusesource.com/>
> > >> skype:
> > >>>> raul.fuse | twitter: @raulvk <http://twitter.com/raulvk>,
> > >>>> @fusenews<http://twitter.com/fusenews>
> > >>>>
> > >>>> <http://twitter.com/fusenews>
> > >>>>
> > >>>> On 16 April 2012 23:09, Chris Geer <ch...@cxtsoftware.com> wrote:
> > >>>>
> > >>>>> Claus,
> > >>>>>
> > >>>>> I'm still struggling with this so I've put together a quick sample
> > >>>> project
> > >>>>> that shows the problem. It consists of an OSGI component that runs
> > >>> under
> > >>>> a
> > >>>>> transaction and posts two JMS messages (one with Camel and one with
> > >> JMS
> > >>>>> APIs) then rolls back the transactions. I would hope to see both
> > >>> messages
> > >>>>> not be delivered but instead what I see if the one sent via camel
> > >> being
> > >>>>> delivered while the other one is rolled back. I'm sure I'm probably
> > >>> doing
> > >>>>> something wrong but I can't figure it out.
> > >>>>>
> > >>>>> Is there a place I can post my sample project where someone might
> be
> > >>> able
> > >>>>> to give it a quick look?
> > >>>>>
> > >>>>> Thanks,
> > >>>>> Chris
> > >>>>>
> > >>>>> On Sat, Apr 7, 2012 at 3:19 AM, Claus Ibsen <claus.ib...@gmail.com
> >
> > >>>> wrote:
> > >>>>>
> > >>>>>> On Thu, Apr 5, 2012 at 5:57 PM, Chris Geer <ch...@cxtsoftware.com
> >
> > >>>>> wrote:
> > >>>>>>> Claus,
> > >>>>>>>
> > >>>>>>> I realize that but I can't explain what I'm seeing. Here is an
> > >>>>> additional
> > >>>>>>> piece of info, here is debug log for the sending of the message.
> > >> As
> > >>>> you
> > >>>>>> can
> > >>>>>>> see, the transaction fields are all null but I don't know if that
> > >>> is
> > >>>>>> normal
> > >>>>>>> or a symptom of the problem.
> > >>>>>>>
> > >>>>>>> 08:51:22,906 | DEBUG | erations/address | JmsConfiguration
> > >>>>>>> | 169 - org.apache.camel.camel-jms - 2.9.2.SNAPSHOT | Sending JMS
> > >>>>> message
> > >>>>>>> to: topic://event-notifications with message:
> > >> ActiveMQBytesMessage
> > >>>>>>> {commandId = 0, responseRequired = false, messageId = null,
> > >>>>>>> originalDestination = null, originalTransactionId = null,
> > >>> producerId
> > >>>> =
> > >>>>>>> null, destination = null, transactionId = null, expiration = 0,
> > >>>>>> timestamp =
> > >>>>>>> 0, arrival = 0, brokerInTime = 0, brokerOutTime = 0,
> > >> correlationId
> > >>> =
> > >>>>>> null,
> > >>>>>>> replyTo = null, persistent = true, type = null, priority = 0,
> > >>>> groupID =
> > >>>>>>> null, groupSequence = 0, targetConsumerId = null, compressed =
> > >>> false,
> > >>>>>>> userID = null, content = null, marshalledProperties = null,
> > >>>>>> dataStructure =
> > >>>>>>> null, redeliveryCounter = 0, size = 0, properties =
> > >>>>> {EntityType=Address,
> > >>>>>>> breadcrumbId=ID-CXTMBP-Chris-local-62052-1333577461603-22-3,
> > >>>>>>> EventType=EntityCreated, ClientID=0}, readOnlyProperties = false,
> > >>>>>>> readOnlyBody = false, droppable = false} ActiveMQBytesMessage{
> > >>>>> bytesOut =
> > >>>>>>> org.apache.activemq.util.ByteArrayOutputStream@51762faf,
> > >> dataOut =
> > >>>>>>> java.io.DataOutputStream@2634b3f1, dataIn = null }
> > >>>>>>>
> > >>>>>>
> > >>>>>> I would only suspect transaction ids being populated in the AMQ
> > >>>>>> message if the message originated from the AMQ broker. Creating a
> > >> new
> > >>>>>> message to be send would most likely not populate TX ids and
> > >> whatnot.
> > >>>>>> But the work is still carried out under the TX manager. (if TX is
> > >>>>>> properly configured and working - yeah thats the hard part).
> > >>>>>>
> > >>>>>>> Here is more of the stack trace that shows the transaction being
> > >>>>>> committed
> > >>>>>>> for some reason.
> > >>>>>>>
> > >>>>>>> 08:51:22,888 | DEBUG | erations/address | TransactionErrorHandler
> > >>>>>>> | 166 - org.apache.camel.camel-core - 2.9.2.SNAPSHOT |
> > >> Transaction
> > >>>>> begin
> > >>>>>>> (0x1f2198ab) redelivered(unknown) for (MessageId:
> > >>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-3 on ExchangeId:
> > >>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-4))
> > >>>>>>> 08:51:22,888 | DEBUG | erations/address | JtaTransactionManager
> > >>>>>>> | 139 - org.springframework.transaction - 3.0.6.RELEASE |
> > >>>>> Participating
> > >>>>>> in
> > >>>>>>> existing transaction
> > >>>>>>> 08:51:22,906 | DEBUG | erations/address | JmsConfiguration
> > >>>>>>> | 169 - org.apache.camel.camel-jms - 2.9.2.SNAPSHOT | Sending JMS
> > >>>>> message
> > >>>>>>> to: topic://event-notifications with message:
> > >> ActiveMQBytesMessage
> > >>>>>>> {commandId = 0, responseRequired = false, messageId = null,
> > >>>>>>> originalDestination = null, originalTransactionId = null,
> > >>> producerId
> > >>>> =
> > >>>>>>> null, destination = null, transactionId = null, expiration = 0,
> > >>>>>> timestamp =
> > >>>>>>> 0, arrival = 0, brokerInTime = 0, brokerOutTime = 0,
> > >> correlationId
> > >>> =
> > >>>>>> null,
> > >>>>>>> replyTo = null, persistent = true, type = null, priority = 0,
> > >>>> groupID =
> > >>>>>>> null, groupSequence = 0, targetConsumerId = null, compressed =
> > >>> false,
> > >>>>>>> userID = null, content = null, marshalledProperties = null,
> > >>>>>> dataStructure =
> > >>>>>>> null, redeliveryCounter = 0, size = 0, properties =
> > >>>>> {EntityType=Address,
> > >>>>>>> breadcrumbId=ID-CXTMBP-Chris-local-62052-1333577461603-22-3,
> > >>>>>>> EventType=EntityCreated, ClientID=0}, readOnlyProperties = false,
> > >>>>>>> readOnlyBody = false, droppable = false} ActiveMQBytesMessage{
> > >>>>> bytesOut =
> > >>>>>>> org.apache.activemq.util.ByteArrayOutputStream@51762faf,
> > >> dataOut =
> > >>>>>>> java.io.DataOutputStream@2634b3f1, dataIn = null }
> > >>>>>>> 08:51:22,907 | DEBUG | erations/address | JtaTransactionManager
> > >>>>>>> | 139 - org.springframework.transaction - 3.0.6.RELEASE |
> > >>>> Registering
> > >>>>>>> after-completion synchronization with existing JTA transaction
> > >>>>>>> 08:51:22,907 | DEBUG | erations/address | TransactionErrorHandler
> > >>>>>>> | 166 - org.apache.camel.camel-core - 2.9.2.SNAPSHOT |
> > >> Transaction
> > >>>>>> commit
> > >>>>>>> (0x1f2198ab) redelivered(unknown) for (MessageId:
> > >>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-3 on ExchangeId:
> > >>>>>>> ID-CXTMBP-Chris-local-62052-1333577461603-22-4))
> > >>>>>>>
> > >>>>>>
> > >>>>>> That last debug logging is just Camel saying that the TX completed
> > >>>>>> successfully (in that leg). Its up to the TX manager when actually
> > >> to
> > >>>>>> commit the TX. If a TX was started outside, then the commit is
> > >>>>>> executed at that point.
> > >>>>>>
> > >>>>>> So this is normal.
> > >>>>>>
> > >>>>>>> On Thu, Apr 5, 2012 at 8:19 AM, Claus Ibsen <
> > >> claus.ib...@gmail.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> On Thu, Apr 5, 2012 at 4:59 PM, Chris Geer <
> > >> ch...@cxtsoftware.com
> > >>>>
> > >>>>>> wrote:
> > >>>>>>>>> Christian,
> > >>>>>>>>>
> > >>>>>>>>> I have that book and that is what I used for a lot of my
> > >>>> reference.
> > >>>>> In
> > >>>>>>>>> fact, they only major difference between his source and mine
> > >> is
> > >>> he
> > >>>>> is
> > >>>>>>>> using
> > >>>>>>>>> Atomikos as the transaction manager and I'm using aries. I am
> > >>>>>> referencing
> > >>>>>>>>> an existing PlatformTransactionManager instead of creating a
> > >>>>>>>>> JtaTransactionManager but PlatformTransactionManager
> > >> implements
> > >>>>>>>>> JtaTransactionManager so it should be ok.
> > >>>>>>>>>
> > >>>>>>>>> As for the datasource, I'm actually publishing it from another
> > >>>> OSGI
> > >>>>>>>>> component as a service so it can be reused. I'm creating it in
> > >>>> code
> > >>>>>> right
> > >>>>>>>>> now as defined below.
> > >>>>>>>>>
> > >>>>>>>>>       BasicManagedDataSource ds = new
> > >> BasicManagedDataSource();
> > >>>>>>>>>
> > >>>>>>>>>       if(xaDataSourceClass != null &&
> > >>>>> !xaDataSourceClass.isEmpty()) {
> > >>>>>>>>>           try {
> > >>>>>>>>>               XADataSource dsi =
> > >>>>>>>>> (XADataSource)Class.forName(xaDataSourceClass).newInstance();
> > >>>>>>>>>               Method setUrl =
> > >>> dsi.getClass().getMethod("setUrl",
> > >>>>> new
> > >>>>>>>>> Class[] {String.class});
> > >>>>>>>>>               setUrl.invoke(dsi, (String)
> > >>>> config.get(CONNSTR_KEY));
> > >>>>>>>>>               ds.setXADataSource(xaDataSourceClass);
> > >>>>>>>>>               ds.setXaDataSourceInstance(dsi);
> > >>>>>>>>>           } catch (IllegalArgumentException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (InvocationTargetException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (NoSuchMethodException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (SecurityException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (InstantiationException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (IllegalAccessException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Couldn't create instance", ex);
> > >>>>>>>>>           } catch (ClassNotFoundException ex) {
> > >>>>>>>>>               throw new
> > >>>> ConfigurationException("xaDataSourceClass",
> > >>>>>>>>> "Class not found", ex);
> > >>>>>>>>>           }
> > >>>>>>>>>       } else {
> > >>>>>>>>>           ds.setDriverClassName((String)
> > >>> config.get(DRIVER_KEY));
> > >>>>>>>>>           ds.setUrl((String) config.get(CONNSTR_KEY));
> > >>>>>>>>>       }
> > >>>>>>>>>
> > >>>>>>>>>       BundleContext context =
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> FrameworkUtil.getBundle(BedrockConnectionPoolFactory.class).getBundleContext();
> > >>>>>>>>>
> > >>>>>>>>>       ds.setTransactionManager(transMgr);
> > >>>>>>>>>
> > >>>>>>>>>       Hashtable<String, String> sp = new Hashtable<String,
> > >>>>> String>();
> > >>>>>>>>>       sp.put(DSNAME_KEY, (String) config.get(DSNAME_KEY));
> > >>>>>>>>>       ServiceRegistration reg =
> > >>>>>>>>> context.registerService("javax.sql.XADataSource",
> > >>>>>>>>> ds.getXaDataSourceInstance(), sp);
> > >>>>>>>>>       regMap.put(id, reg);
> > >>>>>>>>>
> > >>>>>>>>> The transMgr variable above is looking up the Aries
> > >> transaction
> > >>>>>> manager
> > >>>>>>>>> deployed in SMX (same one my JMS code is getting through the
> > >>>>>>>>> PlatformTransactionManager interface).
> > >>>>>>>>>
> > >>>>>>>>> The biggest challenge I've had is that every single camel
> > >>>>> transaction
> > >>>>>>>>> example I've seen starts the transaction INSIDE camel. They
> > >> all
> > >>>>>> resemble
> > >>>>>>>>> the diagram on page 300 of Claus' book. I haven't seen any
> > >>> example
> > >>>>>> where
> > >>>>>>>>> camel is enlisted in an already existing transaction. I was
> > >>> hoping
> > >>>>>> that
> > >>>>>>>> was
> > >>>>>>>>> just because examples are traditionally simple but maybe it
> > >>> wasn't
> > >>>>>>>> designed
> > >>>>>>>>> to do that?
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> Camel does not have its own TX manager etc. All we do is to hook
> > >>>> into
> > >>>>>>>> the Spring TX manager.
> > >>>>>>>> So if there is already a TX in progress, then Camel should just
> > >>> play
> > >>>>>>>> along, and run in that same TX.
> > >>>>>>>>
> > >>>>>>>> The Camel processing occurs in a Spring TX template in its -
> > >>>>>>>> doInTransaction method. That happens when you use the
> > >> <transacted>
> > >>>> in
> > >>>>>>>> the Route.
> > >>>>>>>>
> > >>>>>>>>> Chris
> > >>>>>>>>>
> > >>>>>>>>> On Thu, Apr 5, 2012 at 1:11 AM, Christian Müller <
> > >>>>>>>>> christian.muel...@gmail.com> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Chris,
> > >>>>>>>>>> may be the source code of Claus book "Camel in Action" is
> > >>> helpful
> > >>>>> for
> > >>>>>>>> you
> > >>>>>>>>>> [1].
> > >>>>>>>>>>
> > >>>>>>>>>> Could you als share your datasource configuration with us? It
> > >>> was
> > >>>>>> not in
> > >>>>>>>>>> your post...
> > >>>>>>>>>>
> > >>>>>>>>>> [1]
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
> http://code.google.com/p/camelinaction/source/browse/trunk/chapter9/xa/src/test/resources/spring-context.xml
> > >>>>>>>>>>
> > >>>>>>>>>> Best,
> > >>>>>>>>>> Christian
> > >>>>>>>>>>
> > >>>>>>>>>> On Thu, Apr 5, 2012 at 7:13 AM, Chris Geer <
> > >>>> ch...@cxtsoftware.com>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> We are building an application using ServiceMix (CXF,
> > >> Camel,
> > >>>>>> Karaf...)
> > >>>>>>>>>> and
> > >>>>>>>>>>> we've run into an issue with transactions not propagating
> > >> to
> > >>>>> camel
> > >>>>>>>> routes
> > >>>>>>>>>>> as we'd like them to. We have several OSGI components that
> > >>> run
> > >>>>>> under
> > >>>>>>>>>>> transactions using the Aries transaction management like
> > >> the
> > >>>>>>>> following:
> > >>>>>>>>>>>
> > >>>>>>>>>>>    <bean id="serviceBean" class="<class>">
> > >>>>>>>>>>>       <property name="dataSource" ref="ds"/>
> > >>>>>>>>>>>       <property name="camelContext" ref="camelCtx"/>
> > >>>>>>>>>>>       <tx:transaction method="updateAddress,
> > >> createAddress,
> > >>>>>>>>>>> deleteAddress" value="Required" />
> > >>>>>>>>>>>       <tx:transaction method="getAddress, findAddresses"
> > >>>>>>>>>> value="Supports"
> > >>>>>>>>>>> />
> > >>>>>>>>>>>   </bean>
> > >>>>>>>>>>>
> > >>>>>>>>>>> We have published a DataSource which is transaction aware
> > >> for
> > >>>> our
> > >>>>>>>>>>> components to use. It shows up in SMX as the following:
> > >>>>>>>>>>>
> > >>>>>>>>>>> aries.xa.aware = true
> > >>>>>>>>>>> dsName = ds
> > >>>>>>>>>>> objectClass = javax.sql.DataSource
> > >>>>>>>>>>> service.id = 298
> > >>>>>>>>>>>
> > >>>>>>>>>>> In our components we are able to perform database
> > >>> transactions
> > >>>>> that
> > >>>>>>>>>>> successfully get committed/rolled back as expected without
> > >>>> having
> > >>>>>> to
> > >>>>>>>>>>> manually enlist the JDBC connection. It works great. Those
> > >>> same
> > >>>>>>>>>> components
> > >>>>>>>>>>> also will send various JMS messages as they succeed/fail.
> > >> Our
> > >>>>> goal
> > >>>>>> is
> > >>>>>>>>>> that
> > >>>>>>>>>>> if a component sends a JMS message on success and later
> > >> rolls
> > >>>>> back
> > >>>>>> the
> > >>>>>>>>>> JMS
> > >>>>>>>>>>> message would be retracted. If we lookup a JMS
> > >>>> ConnectionFactory,
> > >>>>>>>> create
> > >>>>>>>>>> a
> > >>>>>>>>>>> connection, session, manually enlist the session into the
> > >>>> current
> > >>>>>>>>>>> transaction and send the message all in code it actually
> > >>> works
> > >>>> as
> > >>>>>>>>>> desired.
> > >>>>>>>>>>>
> > >>>>>>>>>>> What we hope to be able to do however is to remove the code
> > >>> and
> > >>>>> use
> > >>>>>>>> camel
> > >>>>>>>>>>> instead to process the message and pass it along to the JMS
> > >>>>> topic,
> > >>>>>> in
> > >>>>>>>> the
> > >>>>>>>>>>> same transaction that the OSGI component is running in but
> > >> we
> > >>>>> can't
> > >>>>>>>> quite
> > >>>>>>>>>>> get it to work. Below is our latest configuration and code
> > >>> and
> > >>>> at
> > >>>>>> this
> > >>>>>>>>>>> point the message posts to the topic but never rolls back.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Blueprint File
> > >>>>>>>>>>>   <bean id="activemq"
> > >>>>>>>>>>>
> > >>> class="org.apache.activemq.camel.component.ActiveMQComponent">
> > >>>>>>>>>>>       <property name="connectionFactory"
> > >>>>>>>> ref="jmsXaConnectionFactory"/>
> > >>>>>>>>>>>       <property name="transacted" value="true"/>
> > >>>>>>>>>>>       <property name="transactionManager"
> > >>>>>>>> ref="jmsTransactionManager"/>
> > >>>>>>>>>>>   </bean>
> > >>>>>>>>>>>
> > >>>>>>>>>>>   <bean id="mandatory"
> > >>>>>>>>>>>
> > >> class="org.apache.camel.spring.spi.SpringTransactionPolicy">
> > >>>>>>>>>>>       <property name="transactionManager"
> > >>>>>>>> ref="jmsTransactionManager"/>
> > >>>>>>>>>>>       <property name="propagationBehaviorName"
> > >>>>>>>>>>> value="PROPAGATION_MANDATORY"/>
> > >>>>>>>>>>>   </bean>
> > >>>>>>>>>>>
> > >>>>>>>>>>>   <bean id="jmsXaConnectionFactory"
> > >>>>>>>>>>>
> > >>>> class="org.apache.activemq.ActiveMQXAConnectionFactory">
> > >>>>>>>>>>>       <property name="brokerURL"
> > >>>> value="tcp://localhost:61616"/>
> > >>>>>>>>>>>   </bean>
> > >>>>>>>>>>>
> > >>>>>>>>>>>   <reference id="jmsTransactionManager"
> > >>>>>>>>>>>
> > >>>>>>>>
> > >>>>>
> > >>>
> > interface="org.springframework.transaction.PlatformTransactionManager"/>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>   <camel:camelContext id="camelCtx" trace="true">
> > >>>>>>>>>>>       <camel:route>
> > >>>>>>>>>>>           <camel:from uri="direct:genEvent"/>
> > >>>>>>>>>>>           <camel:wireTap uri="direct:wireTap"/>
> > >>>>>>>>>>>           <camel:transacted ref="mandatory"/>
> > >>>>>>>>>>>           <camel:to
> > >>> uri="activemq:topic:event-notifications"/>
> > >>>>>>>>>>>       </camel:route>
> > >>>>>>>>>>>
> > >>>>>>>>>>>       <camel:route>
> > >>>>>>>>>>>           <camel:from uri="direct:wireTap"/>
> > >>>>>>>>>>>           <camel:to uri="log:logger?showAll=true"/>
> > >>>>>>>>>>>       </camel:route>
> > >>>>>>>>>>>   </camel:camelContext>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Code:
> > >>>>>>>>>>>
> > >>>>>>>>>>>       ProducerTemplate pt =
> > >>> camelCtx.createProducerTemplate();
> > >>>>>>>>>>>
> > >>>>>>>>>>>       Map<String, Object> headers = new HashMap<String,
> > >>>>> Object>();
> > >>>>>>>>>>>       headers.put("EventType", eventType);
> > >>>>>>>>>>>       headers.put("ClientID", 0);
> > >>>>>>>>>>>       headers.put("EntityType", "Address");
> > >>>>>>>>>>>
> > >>>>>>>>>>>       pt.sendBodyAndHeaders("direct:genEvent",
> > >>>>>> getAddress(addressID),
> > >>>>>>>>>>> headers);
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> Like I mentioned, the code all works in the success case
> > >> but
> > >>>>>> doesn't
> > >>>>>>>>>>> rollback the JMS message in the failure case. Apparently
> > >> the
> > >>>>>>>> transaction
> > >>>>>>>>>>> context isn't being passed on to the camel route even
> > >> though
> > >>>> it's
> > >>>>>>>> using
> > >>>>>>>>>> the
> > >>>>>>>>>>> same transaction manager under the covers. Is that by
> > >> design
> > >>> or
> > >>>>> is
> > >>>>>>>> there
> > >>>>>>>>>> a
> > >>>>>>>>>>> way to make this scenario work? We'd really like to be able
> > >>> use
> > >>>>> the
> > >>>>>>>> camel
> > >>>>>>>>>>> route approach so we can do more complex things than what I
> > >>>> show
> > >>>>>> here.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Thanks,
> > >>>>>>>>>>> Chris
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> --
> > >>>>>>>> Claus Ibsen
> > >>>>>>>> -----------------
> > >>>>>>>> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
> > >>>>>>>> FuseSource
> > >>>>>>>> Email: cib...@fusesource.com
> > >>>>>>>> Web: http://fusesource.com
> > >>>>>>>> Twitter: davsclaus, fusenews
> > >>>>>>>> Blog: http://davsclaus.blogspot.com/
> > >>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>> --
> > >>>>>> Claus Ibsen
> > >>>>>> -----------------
> > >>>>>> CamelOne 2012 Conference, May 15-16, 2012: http://camelone.com
> > >>>>>> FuseSource
> > >>>>>> Email: cib...@fusesource.com
> > >>>>>> Web: http://fusesource.com
> > >>>>>> Twitter: davsclaus, fusenews
> > >>>>>> Blog: http://davsclaus.blogspot.com/
> > >>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>
> > >>
> >
>

Reply via email to