activemq-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hiram Chirino (JIRA)" <j...@apache.org>
Subject [jira] Assigned: (AMQ-303) Pooled XAConnectionFactory for use with Spring
Date Thu, 15 Jun 2006 04:18:51 GMT
     [ https://issues.apache.org/activemq/browse/AMQ-303?page=all ]

Hiram Chirino reassigned AMQ-303:
---------------------------------

    Assign To: james strachan

James, perhaps we should close this issue out and open one against jencks?

> Pooled XAConnectionFactory for use with Spring
> ----------------------------------------------
>
>          Key: AMQ-303
>          URL: https://issues.apache.org/activemq/browse/AMQ-303
>      Project: ActiveMQ
>         Type: Improvement

>   Components: Connector, JMS client, JCA Container
>  Environment: ActiveMQ 3
>     Reporter: Andy DePue
>     Assignee: james strachan
>     Priority: Minor
>  Attachments: PooledSpringXAConnectionFactory_7_14_05.zip
>
>
> Work is currently underway to provide a JCA Container implementation for Spring, which
would allow fully transaction aware usage of ActiveMQ in Spring.  Current Spring JCA Container
implementations work well for consumers, but are not quite mature for producers.  I've thrown
together (as in, just a couple hours of work) an implementation of XAConnectionFactory that
is both pooled and automatically detects and participates in surrounding JTA transactions.
 There are some caveats to this, however:
> 1. This is considered a temporary solution until Spring JCA Container implementations
have matured to the point where one can access pooled producers that automatically participate
in the (optional) surrounding JTA transaction, even if the transaction was started by a 3rd
party (as opposed to being started by ActiveMQ in response to consuming a message).
> 2. This was thrown together by copying out ActiveMQ's PooledConnectionFactory code and
modifying as needed.  Because of this, there is much code duplication between PooledConnectionFactory
and PooledSpringXAConnectionFactory.  Also, the code ends up being ugly. :)
> 3. This implementation depends on both JTA and Spring.  It requires JTA in order to properly
enlist and handle XA connections/sessions/etc, and it requires Spring in order to manage XASession
resources associated with the current transaction.
> 4. We are still in the process of testing this code.  We are moving our current code
base to Spring 1.2.2 as we need some of the transaction bug fixes made in 1.2.2.  Until we
are fully ported, we will not be able to fully test this code.  If we run into problems/bugs,
we will post updates to this JIRA issue.
> With all that out of the way, usage is very similar to PooledConnectionFactory.  First,
I'll comment on usage, and then show a sample Spring configuration.
> As far as usage is concerned, you must not hold onto sessions and/or producers for long
periods of time, especially across transaction boundaries.  In other words, do not write code
that opens a session and then leaves it open for the duration of your application.  Instead,
your code should do this every time it needs to produce:
> 1. Open a new connection: connectionFactory.createConnection().
> 2. Create a new session: connection.createSessions(...)
> 3. Create a producer: session.createProducer(...)
> 4. Produce messages
> 5. close producer, close session, close connection.
> This pattern may seem heavyweight, but because you are using PooledSpringXAConnectionFactory,
it is actually quite light and efficient.  The following will hold true if you use this pattern:
> 1. You will be using pooled connections, sessions, and producers - so you will be avoiding
the cost of opening/creating them every time, even though you are calling "create" and "close"
methods.
> 2. These sessions will automatically participate in any surrounding JTA transaction.
> 3. All these objects will be properly managed for thread safety.
> 4. If there is a surrounding JTA transaction, then for each thread, the same actual XASession
will be used for the remainder of the transaction.
> Finally, here is an example Spring configuration:
>       <!-- This bean automatically handles pooling and transaction management -->
>       <bean id="jmsConnectionFactory" class="com.marathon.jms.PooledSpringXAConnectionFactory">
>         <property name="connectionFactory">
>           <!-- Actual transaction aware connection factory. -->
>           <bean class="org.activemq.ActiveMQXAConnectionFactory">
>             <property name="brokerURL"><value>... broker URL goes here ...</value></property>
>           </bean>
>         </property>
>         <property name="jtaTransactionManager" ref="transactionManager"/>
>       </bean>
> Note that PooledSpringXAConnectionFactory needs access to a JTA TransactionManager, and
there are two ways to provide it.  If you have exposed the actual JTA javax.transaction.TransactionManager
as a bean in your Spring config, then you would set the "transactionManager" property:
>   <property name="transactionManager" ref="beanNameOfTransactionManager"/>
> If you have exposed a Spring org.springframework.transaction.jta.JtaTransactionManager
in your config, then you could set the "jtaTransactionManager" property:
>   <property name="jtaTransactionManager" ref="beanNameOfSpringJtaTransactionManager"/>
> Either way will allow PooledSpringXAConnectionFactory to get access to the JTA TransactionManager.
 You only need to set one of these properties.

-- 
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
   https://issues.apache.org/activemq/secure/Administrators.jspa
-
For more information on JIRA, see:
   http://www.atlassian.com/software/jira


Mime
View raw message