Now lets dig in...
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 TransactionsWhen 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).
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.
Source: Local and global transaction considerations - IBM docs
Local and global transaction considerations
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.