Transactions and OSGi Applications

You can use transactions in OSGi Applications in a similar way to transactions in Java EE applications. This topic describes the differences when you use transactions with an OSGi application.

You configure transactions at the component level, for example for a bean. You must specify both method and value attributes in the transaction element. Valid values are those that are defined by Java EE, that is, Required, RequiresNew, NotSupported, Mandatory, Supports or Never. For example:
<bean ...>
   <tx:transaction method="updateOrder" value="Required" />
</bean>
You can specify a list of methods where each method is separated by a space or a comma. For example:
<bean ...>
   <tx:transaction method="updateOrder remove" value="Required" />
</bean>
You can use an asterisk character (*) as a wildcard in method names. You can use the wildcard character anywhere in a method name and you can use it multiple times. For example:
<bean ...>
   <tx:transaction method="update*Ord* remove" value="Required" />
</bean>
You can specify multiple method configurations in the same component. For example:
<bean ...>
   <tx:transaction method="update*Ord* remove" value="Required" />
   <tx:transaction method="recordStatus" value="RequiresNew" />
</bean>
Wildcard matching and selection behavior is determined by the following rules:
  1. If more than one transaction element matches a method name, the elements with the least wildcard characters are selected. For example, to match the method updateOrder, the transaction element with the method attribute update* is selected in preference to one with the method attribute update*Ord*.
  2. If more than one transaction element still matches, the elements with the longest method attribute are selected. For example, to match the method updateOrder, the transaction element with the method attribute updateOrd* is selected in preference to one with the method attribute update*.
  3. If more than one transaction element still matches, an IllegalStateException exception is generated.

Transactions and Service Component Architecture (SCA)

You can declare transaction policy at the services level to describe the transactional contract that the service provider offers to the consumer, following the SCA interaction intents model for transactions.

SCA defines two mutually exclusive interaction intents for transactions:
  • sca:propagatesTransaction
    A service with a policy sca:propagatesTransaction indicates that the service will join any transaction that its requester propagates. A service with the following policy indicates that an SCA service will use a transaction if it is supplied. This configuration is also valid for a transaction with a value of Required on a component implementation.
    <sca:service name="Service1" requires="sca:propagatesTransaction">
    </sca:service>
  • sca:suspendsTransaction
    A service with a policy sca:suspendsTransaction indicates that the service will not join any transaction that its requester propagates. The component that provides the service might or might not run under its own transaction. A service with the following policy indicates that the service will not use a transaction if it is supplied. This configuration is also valid for a transaction with a value of RequiresNew or NotSupported on a component implementation.
    <sca:service name="Service1" requires="sca:suspendsTransaction">
    </sca:service>

For an OSGi application, you declare the interaction intents for services in a module Blueprint file. When you write the Blueprint XML, you must consider whether any remote services should allow the caller to provide a transaction, and whether any service you call remotely should be part of your transaction. If you want your application to be able to participate in a transaction from another application, set the interaction intent to propagatesTransaction. However, if your application should run in its own transaction or no transaction, set the property to suspendsTransaction. The default value is suspendsTransaction, so this value is used if no other value is specified.

The interaction intents for services that are declared in a module Blueprint must be consistent with the transaction definitions in a component. The following table shows the mapping between these two properties:
Transaction definition Interaction intent
Required propagatesTransaction
Mandatory propagatesTransaction
RequiresNew suspendsTransaction
Supports propagatesTransaction
NotSupported suspendsTransaction
Never suspendsTransaction
The interaction intent is associated with a service entry in the standard OSGi manner: by recording the intent as a service property in the service registry. The OSGi intent property service.exported.intents is used. This property is defined in the "Remote Services" chapter of the OSGi Service Platform Release 4 Version 4.2 Enterprise Specification.
Services that are implemented by transactional components declare their interaction intent value in the service.exported.intents property. For example, a service in an OSGi application that is backed by a component with a transaction value of Required is registered with the property service.exported.intents=propagatesTransaction. This is equivalent to the following module Blueprint service definition:
<service ref="componentImplementation" 
   interface="com.xyz.MyTransactionalServiceInterface">
   <service-properties>
      <entry key="service.exported.intents" value="propagatesTransaction"/>
   </service-properties>
</service>
SCA references specify their transactional requirements on a service by using the same intents:
<sca:reference name="Reference1" requires="sca:propagatesTransaction">
</sca:reference>
OSGi references specify their transactional requirements on a service by filtering on the OSGi service intents property. The following example code searches for an OSGi service that will participate in a global transaction:
<reference id="transactionalService" 
   interface="com.xyz.MyTransactionalServiceInterface"
   filter ="(service.exported.intents=propagatesTransaction)"/>

The default transaction policy is Required.

For more information about the SCA interaction intents model for transactions, see the "Using intents in an OSGi application" section of SCA programming model support in OSGi Applications, and SCA transaction intents.

Handling exceptions

The following table shows how exceptions are handled for transactions in OSGi Applications.

Table 1. Exception handling for transactions in OSGi Applications
Transaction scope Transaction strategies Exception generated Container action Client view
Client-initiated transaction. The client starts a transaction and propagates it to the bean.

Required
Mandatory
Supports

Declared exception Regenerate the declared exception. The client receives an exception. The client transaction is not affected.
All other exceptions and errors Log the exception or error. Mark the transaction for rollback. Regenerate the exception or error. The client receives an exception. The client transaction is marked for rollback.
Container-managed transaction. A transaction is started before the bean is invoked and ends when the method completes.

Required
RequiresNew

Declared exception Attempt to either commit or roll back the transaction, and regenerate the declared exception. The client receives an exception. The client transaction is not affected.
All other exceptions and errors Log the exception or error. Mark the transaction for rollback. Regenerate the exception or error. The client receives an exception. The client transaction is not affected.
The bean is not part of a transaction. Any client transaction is not propagated to the bean, and no new transaction is started.

Never
NotSupported
Supports

Declared exception Regenerate the declared exception. The client receives an exception. Any client transaction is not affected.
All other exceptions and errors Regenerate the exception. The client receives an exception. Any client transaction is not affected.

Local transactions

In WebSphere® Application Server, Blueprint components always run in a transaction. If you do not configure a global transaction, by using the transaction Blueprint namespace, all methods run in their own local transaction. For more information, see Local transaction containment (LTC).

This local transaction is application-managed with default behaviour. That is, the Resolver attribute of the transaction is set to Application and the Unresolved action attribute is set to Rollback. The transaction is set to roll back any uncommitted changes. Therefore, any transactional work, such as a database update, that runs in a method of a Blueprint bean, and that is not committed when the method returns, is rolled back, and therefore discarded.


Concept topic

Terms of use | Feedback


Timestamp icon Last updated: Tuesday, 20 September 2011
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=matt&product=was-nd-zos&topic=ca_transactions

Copyright IBM Corporation 2009, 2011. All Rights Reserved.
This information center is powered by Eclipse technology. (http://www.eclipse.org)