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.
<bean ...>
<tx:transaction method="updateOrder" value="Required" />
</bean>
<bean ...>
<tx:transaction method="updateOrder remove" value="Required" />
</bean>
<bean ...>
<tx:transaction method="update*Ord* remove" value="Required" />
</bean>
<bean ...>
<tx:transaction method="update*Ord* remove" value="Required" />
<tx:transaction method="recordStatus" value="RequiresNew" />
</bean>
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:service name="Service1" requires="sca:propagatesTransaction">
</sca:service>
<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.
Transaction definition | Interaction intent |
---|---|
Required | propagatesTransaction |
Mandatory | propagatesTransaction |
RequiresNew | suspendsTransaction |
Supports | propagatesTransaction |
NotSupported | suspendsTransaction |
Never | suspendsTransaction |
<service ref="componentImplementation"
interface="com.xyz.MyTransactionalServiceInterface">
<service-properties>
<entry key="service.exported.intents" value="propagatesTransaction"/>
</service-properties>
</service>
<sca:reference name="Reference1" requires="sca:propagatesTransaction">
</sca:reference>
<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.
The following table shows how exceptions are handled 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 |
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 |
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 |
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. |
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.