Ce contenu n'est pas disponible dans la langue sélectionnée.
6.5. Transaction Policy
Transaction Policy defines implementation and interaction policies that relate to transactional quality of service in components and their interactions. The transaction policies are specified as intents which represent the transaction quality of service behavior offered by specific component implementations or bindings.
6.5.1. Transaction Interaction Policy
You can specify the Transaction Interaction Policy by using a component service or component reference definition's
requires attribute. Here is an example:
<service name="WorkService" requires="propagatesTransaction">
Valid values for the Transaction Interaction Policy intents are:
propagatesTransaction: Indicates that a global transaction is required when a service is invoked. If no transaction is present, the SwitchYard generates an error at runtime.suspendsTransaction: Indicates that if a transaction exists, the SwitchYard runtime suspends it before the service implementation is invoked and resumes it after the service invocation. This setting allows you to separate a gateway binding's transactional context from the transactional context of the service implementation.
You can attach the mutually exclusive
propagatesTransaction and suspendsTransaction intents either to an interface or explicitly to a service and reference XML element in order to describe how any client transaction context is made available and used by the target service component.
Figure 6.1. Transaction Interaction Policy
6.5.2. Transaction Implementation Policy
You can specify the Implementation Interaction Policy by using a component service or component reference definition's
requires attribute. Here is an example:
<implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global">
Valid values for Transaction Implementation Policy intents are:
managedTransaction.Global: Indicates that this service implementation runs under a global transaction. If no transaction is present, the SwitchYard runtime creates a new JTA transaction before the execution. The SwitchYard runtime commits this newly created transaction at the end of service execution.managedTransaction.Local: Indicates that this service implementation runs under a local transaction. If a transaction exists, the SwitchYard runtime suspends it. SwitchYard always creates a new JTA transaction before execution. The SwitchYard runtime commits this newly created transaction and resumes the suspended transcation after the service invocation.NoteAs the local transaction does not propagate its transaction through the reference, you must mark all of the component reference assuspendsTransaction. If not, the SwitchYard runtime generates an error.noManagedTransaction: Indicates that this service implementation does not run under any managed transaction. If a transaction exists, the SwitchYard runtime suspends it before the service implementation is invoked and resumes it after the service invocation.
You can use the mutually exclusive
managedTransaction and noManagedTransaction intents to describe the transactional environment required by a service component.
Scope of Support
Currently, the following gateways are transaction aware:
- Camel JMS Gateway (binding.jms)
- Camel JPA Gateway (binding.jpa)
- Camel SQL Gateway (binding.sql)
- JCA Gateway (binding.jca)
- SCA Gateway (binding.sca)
Note
BPM service (implementation.bpm) always need a JTA transaction if the persistence is enabled. It synchronizes with incoming transaction if exists, otherwise it begins a new JTA Transaction and commit/rollback by itself.
Note
If your application has multiple camel-jms bindings which are bound to the same JMS provider, you need to define distinct connection factory for each binding to get Transaction Policy working. otherwise, transaction can't be suspended as expected. Similarly, distinct xa-datasource is needed to get Transaction Policy working on camel-jpa and camel-sql. (https://issues.jboss.org/browse/SWITCHYARD-1285)
Figure 6.2. Transaction Implementation Policy
