How to manage transactions for a SwitchYard service with SQL bindings ?
Environment
- Red Hat JBoss Fuse Service Works (FSW)
- 6.0.0
Issue
- Consider a
SwitchYard
application which has the following architecture.
SQL Binding (Composite Service) –> Bean Service -> SQL Binding (Composite Reference)
As per the above architecture user wants to start the transaction during the start of the execution of the first SQL Binding
(Composite Service) which spans till when SQL Binding
at the reference has executed their statements . If everything works fine user would like to commit the transaction or rollback in case of errors. But this does not seem to work out for many users as it appears that as soon as the first SQL Binding
(Composite Service
) executes the statement and then the transaction commits it.
- So how should users write the code so the chain from the first SQL Binding till the last one is covered in one transaction ?
- How to manage transactions for a
SwitchYard
service withSQL bindings
?
Resolution
- As per our documentation,
SwitchYard
provides a mechanism for it's users to specify theTransaction policies
forSwitchYard
services in it's configuration with the help ofTransaction Policy
configuration visible through ourJBDS
/Eclipse
basedSwitchYard
editor as shown here [1] . This way users can define the implementation and interaction policies (in terms ofTransaction
) betweenSwitchYard
components and their interactions. - Users can specify the transaction interaction policy at the
service
level usingrequires
attribute like this way to choose any of the following transaction policies.
<service name="WorkService" requires="propagatesTransaction">
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 users to separate a gateway binding's transactional context from the transactional context of the service implementation.
Transaction implementation policy
can be defined atcomponent service
orcomponent reference
configuration usingrequires
attribute as shown here. TheTransaction Implementation Policies
can be chosen from the ones listed below.
<implementation.bean class="org.switchyard.quickstarts.demo.policy.transaction.WorkServiceBean" requires="managedTransaction.Global">
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.
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.
Note Currently for SQL binding, users should use the Camel SQL Gateway
as it is supported.
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
Comments