How to manage transactions for a SwitchYard service with SQL bindings ?

Solution Unverified - Updated -

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 with SQL bindings ?

Resolution

  • As per our documentation, SwitchYard provides a mechanism for it's users to specify the Transaction policies for SwitchYard services in it's configuration with the help of Transaction Policy configuration visible through our JBDS/Eclipse based SwitchYard editor as shown here [1] . This way users can define the implementation and interaction policies (in terms of Transaction) between SwitchYard components and their interactions.
  • Users can specify the transaction interaction policy at the service level using requires 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 at component service or component reference configuration using requires attribute as shown here. The Transaction 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.

[1] Transaction Policy

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