Show TOC

Procedure documentationConfiguring Transaction-Related JMS Connection Factory Properties Locate this document in the navigation structure

 

Local and Distributed Transactions

Transactions represent a sequence of operations treated as a unit to satisfy a request and to ensure database integrity. In a transaction either all operations are successful (committed) or all operations fail (are rolled back). There are two types of transactions — local and distributed. Local transactions refer to one system only, while the distributed transactions are related to multiple systems such as databases (JDBC) and messaging systems (JMS). Distributed transactions are implemented according the XA specification.

JMS and JDBC connections

A common case of distributed transactions is one containing a JMS and a JDBC resource. For example, consider an online bookstore application. There is a sequence of operations that must be executed atomically: a particular amount of money has to be withdrawn from the customer's account, transferred to the account of the bookstore and the book has to be delivered to the customer. These operations may involve exchange of JMS messages and requests to a database. To prevent inconsistencies due to failure of transactions in distributed systems, the Transaction Manager commits or rolls back all resources together.

The following graphic shows the sequence of operations in the general case. The JDBC connection used by the application is different from the connection used by the JMS Provider. In this case, without using the XA specification, it is difficult to guarantee consistence of the global transaction because the two JDBC connections are independent.

This graphic is explained in the accompanying text.

The JMS Provider and the application use different JDBC connections

One way to guarantee transactional consistence is to use one and the same JDBC connection for both the JMS operations and the application's database operations. In this case, all database operations will be committed or rolled back by a single JDBC connection.

The following graphic shows the sequence of operations when the JDBC connection is reused by the application and the JMS Provider.

This graphic is explained in the accompanying text.

The JMS Provider and the application share the same JDBC connection

Another way to guarantee transactional consistence (without reusing the JDBC connection) is to use the two-phase commit (XA) capabilities of the underlying database and JMS Provider.

Types of JMS Connection Factories and their SAP-specific transaction modes

The JMS specification defines two groups of JMS connection factories — XA connection factories and non-XA connection factories. Each group contains three types of JMS connection factories — XAConnectionFactory, XAQueueConnectionFactory and XATopicConnectionFactory for the XA connection factories and ConnectionFactory, QueueConnectionFactory and TopicConnectionFactory for the non-XA connection factories.

There is one additional mode, configured by an optional property of the connection factories — Optimized mode. This mode is valid for both XA and non-XA connection factories.

The Optimized mode allows the JMS Provider to reuse the JDBC connection of the application. This is useful when your application uses both JMS and custom database access in one transaction. The Optimized mode can be used only with connection factories belonging to Local JMS Virtual Providers because there is no way to share the JDBC connection across several cluster nodes.

More information about the Local and Global JMS Virtual Providers and how you can configure them: JMS Clustering and Failover

The transaction mode of a JMS connection factory is configured in the jms-resources.xml.

Procedure

You can configure the Optimized mode of the JMS connection factories using the optional runningMode property in the <connection-factory> tag in the jms-resources.xml.

Syntax Syntax

  1. <connection-factory>
    		<name>MyQueueConnectionFactory</name>
    		<sap-local-factory-type>
    			<type>javax.jms.QueueConnectionFactory</type>
    			<virtual-provider>testRunningMode</virtual-provider>
    			<user-name>Administrator</user-name>
    		<property>
    			<description>runningMode</description>
    			<config-property-name>Optimized</config-property-name>
    		</property>
    		</sap-local-factory-type>
     </connection-factory>
    
End of the code.

Syntax Syntax

  1. <connection-factory>
    		<name>MyXATopicConnectionFactory</name>
    		<sap-local-factory-type>
    			<type>javax.jms.XATopicConnectionFactory</type>
    			<virtual-provider>testRunningMode</virtual-provider>
    			<user-name>Administrator</user-name>
    		<property>
    			<description>runningMode</description>
    			<config-property-name>Optimized</config-property-name>
    		</property>
    		</sap-local-factory-type>
     </connection-factory>
    
End of the code.