Local transactions

Some software platforms do not provide transaction coordination as part of the kernel operating system. In these environments, a resource manager (RM) typically provides RM-specific transactional functions so that, for at least the resources that the resource manager controls, applications can rely on the data integrity, coherency, and consistency attributes that transactions provide. For example, a resource manager might define RM-specific commit functions, such as MQCMIT and SQLCMIT, that an application can use to commit its resources.

When a syncpoint coordinator is available and coordinating a transaction which could involve multiple resource managers, the transaction is known as a global transaction. When, instead, each resource manager involved is seperately coordinating its own changes, and only its changes, the transaction is known as a local transaction. In a typical local transaction, the application changes resources owned by a given resource manager (such as using a Java™ Database Connectivity (JDBC) connection for a relational database) and then uses an RM-specific commit function (such as the commit() method for JDBC connections) to commit the changes.

When operating in a local transaction environment, called local transaction mode, a resource manager must behave as follows:

In local transaction mode, an application acts as its own resource coordinator, and each resource manager must behave independently. It is possible that an application, in the absence of a global transaction coordinator, needs to process multiple resources owned by different resource managers. In local transaction mode, each resource manager is independent. The application acts as transaction coordinator and can, if necessary, direct different resource managers to different outcomes.
A resource manager must treat separate attachments or connections to the same application independently. It is possible that an application might need to process multiple resources owned by the same resource manager. If an application defines two separate attachments or connections to the same resource manager in local transaction mode, the resource manager must treat each connection independently. This independence allows an application to commit some connections to the same resource manager and roll back others.
A resource manager that defines local commit functions allows its resources to be accessed locally. When in local transaction mode, a resource manager does not permit global commit services like Commit_UR and Application_Commit_UR. If a resource manager does not provide its own local commit functions, a connection to the resource manager should use commit-on-return when in local transaction mode.
If a connection is made to a resource manager when in local transaction mode, the connection is known as a local connection. If a local connection connects the application to a work manager, and the connection touches resources managed by different resource managers as a result, it is the responsibility of the work manager to act as the coordinator of those resources.

There are also rules that govern the transition between local transaction mode and global transaction mode. There are rules that govern when a transition between local and global transaction mode is allowed:

Local to global is only allowed when there are no uncommited local connections.
Global to local is only allowed when the global transaction is in-reset.

Global commit and rollback functions, such as SRRCMIT, are not allowed in local transaction mode. Local commit and rollback functions, such as MQCMIT, are not allowed in global transaction mode.

Implementing local transactions on z/OS involves the participation of four separate entities:

The transaction coordinator, RRS. RRS is responsible for keeping track of when there is an active global or a local transaction associated with a given work context. RRS is also responsible for:

Ensuring that global transaction functions, such as commit and rollback, are not permitted when a local transaction is active for a given work context
Preventing the start of a global transaction when the current UR state is in-flight or beyond
Rejecting global commit functions against URs which are in local transaction mode, known as local URs, which are in any state except in-reset
Notifying resource managers, by driving their appropriate syncpoint exit routines, when a work manager or an application has ended a global transaction

A work manager, such as WebSphere for OS/390. A work manager is responsible for ensuring that the correct transactional environment is established or restored before it dispatches the application. A work manager is also responsible for:

Ensuring that the default transaction mode is correctly set either for the address space or for each individual context
Enforcing transaction policy on the application or method exit and invoking End_Transaction to take the appropriate action

A resource manager, such as DB2®. A resource manager must manage its resources correctly regardless of whether the transaction mode is local or global. A resource manager is also responsible for:

Notifying RRS if it supports local transaction mode
Ensuring that its local transactional functions are not executed when the transaction environment for the work context is global
Registering its uncommitted local interest with RRS
Deleting its interest when the local resource is committed or rolled back via the resource manager's local transaction functions
Correctly using the local transaction flag in its COMMIT, BACKOUT, and COMPLETION exit routines
Using its own logs to recover its local transactions during restart, because local URs are not written to RRS logs

An application. An application defines the demarcation between local transaction mode and global transaction mode, based on the transaction mode set by a work manager when it dispatches the application.