Transactions and OSGi Applications

Transactions and OSGi Applications

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

Blueprint transactions

We configure transactions by specifying one or more <transaction> elements. The <transaction> element is defined in a Blueprint namespace extension, http://aries.apache.org/xmlns/transactions/v1.0.0. Therefore, specify a namespace prefix for this extension in the <blueprint> element. In the examples that follow, the prefix "tx" is used; this prefix is specified as follows:
<blueprint
  xmlns="http://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">
We configure transactions at the component level, for example for a bean. Specify both method and value attributes in the transaction element. Valid values are those defined by Java EE, that is, Required, RequiresNew, NotSupported, Mandatory, Supports or Never. For example:
<bean ...>
   <tx:transaction method="updateOrder" value="Required" />
</bean>
We 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>
Use an asterisk character (*) as a wildcard in method names. Use the wildcard character anywhere in a method name and we can use it multiple times. For example:
<bean ...>
   <tx:transaction method="update*Ord* remove" value="Required" />
</bean>
We 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:

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*.
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*.
If more than one transaction element still matches, an IllegalStateException exception is generated.

Transactions and Service Component Architecture (SCA)

We 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 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 bean 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 bean 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 bean implementation.
<sca:service name="Service1" requires="sca:suspendsTransaction">
</sca:service>
Handle exceptions

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

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
andatory
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 we do not configure a global transaction, using the transaction Blueprint namespace, all methods run in their own local transaction. 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.

Use the transaction service
Configure transactional deployment attributes
OSGi Service Platform Release 4 Version 4.2 Enterprise Specification

File name: was340.html

prettyPrint();

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 andatory 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.