DataSource , Transactions , Compensation Activity

                                            XA AND NON XA DATA SOURCE

An XA transaction is a "global transaction" that may span multiple resources.

A non-XA transaction always involves just one resource.

An XA transaction involves a coordinating transaction manager, with one or more databases (or other resources, like JMS) all involved in a single global transaction.

Non-XA transactions have no transaction coordinator, and a single resource is doing all its transaction work itself (this is sometimes called local transactions). 

Example of non-XA - a Servlet or EJB or plain old JDBC in a Java application talking to a single database.

XA gets involved when you want to work with multiple resources. 2 or more databases, a database and a JMS connection, all of those plus maybe a JCA resource - all in a single transaction. In this scenario, you'll have an app server like WebSphere or WebLogic or JBoss acting as the Transaction Manager, and your various resources (Oracle, Sybase, IBM MQ JMS, SAP, whatever) acting as transaction resources.

Your code can then update/delete/publish/whatever across the many resources. When you say "commit", the results are committed across all of the resources. When you say "rollback", _everything_ is rolled back across all resources.

The Transaction Manager coordinates all of this through a protocol called Two Phase Commit (2PC). This protocol also has to be supported by the individual resources.

In terms of datasources, an XA datasource is a data source that can participate in an XA global transaction. A non-XA datasource generally can't participate in a global transaction.

------------------------------------------------------------------------------------------------

                                                         Transactions

* Services can be of two types:

1. Non-Transactional Services

2. Transactional Service

* Non-Transactional services are the services that does not modify data.

  E.g. File Adapter, FTP Adapter

* Transactional service can be defined as any service that performs DML operations, where each operation are subject to ACID(Atomicity, Consistency, Isolation, Durability) principles.

* Transactional services are implemented as a java web services or adapter services which are invoked from SOA using BPEL or Mediator

* Transactional boundaries depend on context, configurations and environment of the services that are implemented and invoked.

* Transactional semantics differs for the services that are invoked synchronously compared with services invoked asynchronously.

 Transaction Boundaries

* Transaction boundaries depends on the type of interaction

              1. Starts when a service is invoked(operation begins) and Ends when a service ends(operation completes)

              2. Propagates across synchronous services which can:

* Joining an existing transaction (By default it will Join in Global Tx)

* End the existing transaction(Can be achieved by Dehydration)

Propagate the transaction to another synchronous services

1.     Terminate when invoking an asynchronous service, which:

        Ends or suspends the existing transaction

        Starts new independent transaction

     Transactional Service Implementation

* Services with transactional behavior can be implemented using

   1. Web services(i.e. JWS, Spring Web services, ADF-BC) that execute SQL transactions

   2. Database Adapter

   3. Service Data Objects

BPEL Transaction

BPEL processes are:

* Transient, when they don’t have any dehydration points i.e. execute start to end without dehydration

* Durable, when one or more dehydration points occur during execution

BPEL Transactions are:

* Begin at the start of the process. The first activity(Receive / Pick) marks the start of the bpel process.

* Ends at the end of the transient(Synchronous) process, when it send the reply to its client, or when the dehydration point occurs in a durable(asynchronous) process.

* If the a fault occurs before these end conditions, the transaction is rolled back to the start and unhandled faults are returned to caller.

BPEL Transactional Behavior

JTA (Java Transaction API) is used with the request and when:

* If exists, the local transaction joins the global JTA transaction when transaction property is set.

* If does not exist then new transaction is started.

A transaction is completed when it encounters a break point activity(causing dehydration) or reaching end of flow.

BPEL Transaction and Delivery properties

Transaction boundaries between different BPEL services are controlled by 2 properties i.e. Delivery Property and Transaction property

Delivery property can have 3 values. 

1)- async.persit  

2)- async.cache 

3)- sync

Transaction property can have 2 values. 

1)- Required 

2)- Requires New

<component name=”TransactionBpel” version=”2.0″>

<implementation.bpel src=”BPELASynchCall.bpel”/>

<property name=”bpel.config.transaction” type=”xs:string” many=”false”>required</property>

<property name=”bpel.config.oneWayDeliveryPolicy” type=”xs:string” many=”false”>async.persist</property>

</component>

case1: If BPEL Process is Async or one-way process then, Delivery property is used

async.persit: Delivery messages are persisted in the database in table dlv_message. With this setting, reliability is obtained with some performance impact on the database.

When the client initiates a process instance, an invocation request is placed in an internal queue. Inside Oracle BPEL Server, a message-driven bean (MDB), WorkerBean, monitors the queue for invocation requests. When a message is dequeued, Oracle BPEL Server allocates a thread to process the message.

async.cache : Incoming delivery messages are kept only in the in-memory cache. If performance is preferred over reliability, this setting should be considered.

Message are not dehydrated into dlv_message table. Rest all is same as async.persist.

sync : Directs Oracle BPEL Server to bypass the scheduling of messages in the invoke queue, and invokes the BPEL instance synchronously. In some cases this setting can improve database performance.

case2: If BPEL Process is Sync process then, transaction boundary between client and bpel process is controlled by “Transaction” property

Required : This makes the BPEL process execute as part of the calling transaction. If no calling transaction exists, it will create a new one.

RequiresNew: This is the default value and makes the BPEL process execute as a separate transaction. Any existing transaction will be suspended.

Adapters

Transactional adapters that supports Two Phase commit:

DB Adapter

JMS Adapter

AQ Adapter

Oracle Apps Adapter

Non transactional adapters

File Adapter

FTP Adapter

--------------------------------------------------------------------------------------------------------

                                                          Compensation Activity

Problem: Transactions do not work with asynchronous services.

* ACID principles and XA transactions cannot be applied across asynchronous invocations

* Transactions can be managed for synchronous services, provided all invocations are synchronous.

Solution: Compensation handling, which enables an asynchronous invocation to execute:

* An operation that performs a transaction

* An operation that perform reverse of previously completed transaction.

Keep Learning ! Cheers Guys!!

Kavindra Sahu