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.

Blueprint transactions

You 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, you must 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="https://www.osgi.org/xmlns/blueprint/v1.0.0"
  xmlns:tx="http://aries.apache.org/xmlns/transactions/v1.0.0">

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:

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)

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 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>
```

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.
	Required Mandatory Supports	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.
	Required RequiresNew	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.
	Never NotSupported Supports	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.

This local transaction is application-managed with default behavior. 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.