Local and Global Transaction. And example with Oracle BPEL Application.

JTA Transactions - Local and Global Transaction. And example with Oracle BPEL Application.

This Blog is about understanding the basics of transaction in J2EE level and how this can be translated to Oracle, BPEL conceptually. This does not limit the interpolation of this concept in simple Java projects as well.

Now lets dig in...


Transactions

J2EE supports two kinds of transactions:

• Local Transactions - A local transaction is internal to a single resource.
• Global Transactions - A global transaction is created by an external transaction manager (JTA) and is used to scope work on multiple resources.
  

Local Transactions

When a managed data source is configured for local transactions it returns connections that can participate in local transactions but cannot participate in global transactions. This means that the connections will not be enlisted in global transactions. The data source will set the auto commit to true for retrieved connections. However, it is up to the client to determine how the connections will be used in local transactions. That is, the client can change the auto-commit mode by using setAutoCommit() on a connection.


Local transactions are transactions associated with a particalar data source (means they are resource-specific). the most common example would be a transaction associated with a JDBC connection.

Global Transactions (XA)

When a managed data source is configured for global transactions, it returns connections that can participate in global transactions. A global transaction (also called a distributed transaction) enlists more than one resource in the transaction.

Global Transactions provide the ability to work with multiple transactional resources (typically relational databases and message queues).

Sources:
Oracle® Containers for J2EE Services Guide 10g (10.1.3.1.0)
Question: Difference between local and global transaction ? - AllInterview


Now putting this in SOA, Concept for better understanding:

Diag Source: Oracle® Containers for J2EE Services Guide 10g (10.1.3.1.0)Part Number B28958-01

So with the above image, lets make some assumptions,

hint: BPEL needs a JDBC connection for its dehydration purpose.

The client Tx is the main BPEL process and the new Tx is probably the adapter / another BPEL process invocation process with in the main BPEL process.


In a local transaction setup, client Tx will be a separate transaction and new Tx will be on its own.
In a global transaction setup, new Tx will be a part of or will participate with client Tx.

In another scenario, we can have one client Tx as local and two new Tx as XA. In this scenario the BPEL process will be on tis own and the two new  Tx will be part of one global Tx.

for example this case will apply where you have one BPEL process and you have two or more DB adapters in the BPEL process. Which means, all the DB adapter Tx will roll back if any one of the DB adapters fail with an error.


Additional Info:

Source: Local and global transaction considerations - IBM docs

Local and global transaction considerations

Applications use resources, such as Java Database Connectivity (JDBC) data sources or connection factories, that are configured through the Resources view of the administrative console. How these resources participate in a global transaction depends on the underlying transaction support of the resource provider.

For example, most JDBC providers can provide either XA or non-XA versions of a data source. A non-XA data source can support only resource manager local transactions (RMLT), but an XA data source can support two-phase commit coordination, as well as local transactions.

If an application uses two or more resource providers that support only RMLTs, atomicity cannot be assured because of the one-phase nature of these resources. To ensure atomic behavior, the application should use resources that support XA coordination and should access them within a global transaction.
If an application uses only one RMLT, atomic behavior can be guaranteed by the resource manager, which can be accessed in a local transaction containment (LTC) context.

An application can also access a single resource manager in a global transaction context, even if that resource manager does not support the XA coordination. An application can do this because the application server performs an "only resource optimization" and interacts with the resource manager in a RMLT. In a global transaction context, any attempt to use more than one resource provider that supports only RMLTs causes the global transaction to be rolled back.

At any moment, an instance of an enterprise bean can have work outstanding in either a global transaction context or an LTC context, but not both. An instance of an enterprise bean can change from running in one type of context to the other (in either direction), if all outstanding work in the original context is complete. Any violation of this principle causes an exception to be thrown when the enterprise bean tries to start the new context.