Introduction

Current enterprise computing environments are an interconnection of distributed transaction processing and messaging middleware systems (legacy and distributed systems). Enterprise business data is spawned across such interconnected systems and databases in heterogeneous networks.

When designing applications that update data on more than one transaction processing and messaging middleware system, it is important to remember that network or system failures can occur that might result in data inconsistency. So it's essential to synchronise those interconnected systems to maintain data integrity. The mechanism to keep the recoverable resources (such as files, databases, and tables) in a consistent state across those interconnected systems is called synchronization (sometimes shortened to sync point). Sync points are implied at the beginning and end of a transaction.

This article discusses the importance of synchronization and the synchronization methods supported by various IBM transaction processing and messaging middleware systems when integrated with CICS Transaction Server (CICS TS).

Back to top

Importance of synchronization

Consider a single system where an application moves records between two tables TABLEA and TABLEB, as shown in Figure 1. If a problem occurs, for example if data is corrupted in one of the files, or a transaction abends, the transaction processing monitor backs out the changes that were made before the problem occurred. Consequently, the data in the database return to their state at the time the transaction was initially invoked.

Now consider the case where TABLEB resides on a remote system, as shown in Figure 2. The work of the application is effectively split into two transactions, TRN1 and TRN2. Because the application is distributed, it is now difficult for TRN1 running in the local system to detect problems with adding the record to TABLEB on the remote system. If TRN1 cannot detect these problems, then it might delete a record from TABLEA that has not been added to TABLEB, and cause the record to be lost.

The solution is to use a form of acknowledgment processing so that the two transactions in the application can ensure that they each complete their task successfully. The exact form of this acknowledgment depends on the requirements of the application.

As shown in Figure 3, after TRN2 writes a record to TABLEB, it can send a message to TRN1, indicating that the record can be deleted from TABLEA.

Thus a record can never be lost, because TRN1 deletes the record from TABLEA only when it knows that the record is written to TABLEB. However, if TRN1 fails after it receives the message to delete the record, but before the record is actually deleted from TABLEA, the record appears twice, once in TABLEA and again in TABLEB.

In the next sections, we’ll look at methods for synchronizing data updates between transaction processing and messaging middleware products.

Back to top

Synchronization methods

There are two methods through which synchronization is addressed with respect to CICS Transaction Server:

• Synchronization levels
• X/Open DTP XA

Let's look at each of these methods.

Synchronization levels

A two-way communication between two applications is called a conversation. The synchronization level (synclevel) specifies the degree to which the conversation is transactional. Since applications have different requirements, SNA defines three levels of support that allow an application to coordinate updates across a number of systems. These levels of support are called synchronization levels:

• Synchronization level 0 (NONE): TPM (Transaction Processing Monitor) provides no synchronization support. The application must code its own.
• Synchronization level 1 (CONFIRM): TPM provides the ability to send simple acknowledgment requests.
• Synchronization level 2 (SYNCPOINT): TPM provides the ability for two or more TPM’s to treat the updates made by an application on these systems as one logical unit of work (LUW). When the application requests a synchronization point the updates on the remote systems are committed if, and only if, updates to recoverable data made locally by the transaction are also committed. If a failure occurs for example, the transaction abends before all involved systems have agreed to commit, all the updates for the application on each of the systems are backed out Alternatively all updates are backed out if the application issues Rollback.

X/Open DTP XA

X/Open DTP XA is a standard that every transaction manager implements to coordinate the resource managers connected with the transaction processing monitor. With this synchronization type, the transaction manager coordinates syncpoint, rollback, commit, and failure recovery of all work involved in the unit of work, including queues, files and resources that are managed by the resource manager.

Back to top

Synchronization between TXSeries and CICS Transaction Server

TXSeries for Multiplatforms is a non-J2EE distributed transaction processing monitor, part of the IBM CICS family of products that provides business critical transaction and integration capabilities for enterprise environments.

TXSeries interoperates with CICS TS on z/OS using these methods:

• Local SNA support
• SNA support via the CICS PPC Gateway server

Using local SNA support

Local SNA support requires an appropriate SNA product to be installed and configured on the same machine as the TXSeries for Multiplatforms region. With local SNA support, you can use synchronization levels 0 and 1.

Figure 4 shows a TXSeries region in a distributed environment connecting to a CICS TS region on z/OS. It updates the DB2 database on the mainframe, therefore synchronization level 1 is sufficient to maintain data integrity.

Using a PPC Gateway server to communicate across SNA

TXSeries can communicate with an SNA network by using a PPC Gateway server. CICS uses TCP/IP to communicate with the PPC Gateway server, and the PPC Gateway server provides a link to the SNA network.

A PPC Gateway server supports sychronization levels 0, 1, and 2.

Figure 5 shows a TXSeries Region on a distributed environment connecting to a CICS TS region on z/OS. This scenario spawns business data across a database connected to TXSeries and a database connected to CICS Transaction Server on z/OS. If the business logic updates the data in both of the databases, then it needs synchronization level 2. Therefore in this case you need to use PPCGateway Server to provide a synchronization level 2 mechanism between TXSeries and CICS TS.

Back to top

Synchronization between WebSphere Application Server and CICS Transaction Server

WebSphere Application Server is a J2EE-based transaction processing manager available for a distributed environment, and for z/OS. In an enterprise environment, WebSphere Application Server needs to connect to CICS Transaction Server to utilize its services.

A J2EE transaction processing manager like WebSphere Application Server can connect to CICS TS by using the J2EE Connector Architecture (JCA), which defines a standard architecture for connecting the J2EE platform to heterogeneous enterprise information systems like CICS Transaction Server. WebSphere Application Server can connect to CICS TS using a gateway product called CICS Transaction Gateway. CICS Transaction Gateway provides JCA adapter facilities to connect and provide synchronization between WebSphere Application Server and CICS TS.

In this section we look at some topologies and details about the synchronization levels supported by the CICS Transaction Gateway resource adapters.

One-phase commit processing

Figure 6 shows the first topology, which uses the ECI resource adapter for one-phase commit processing (similar to sync level 1).

In this topology:

• You use the CICS ECI resource adapter to integrate with CICS Transaction Server using CICS Transaction Gateway.
• The CICS ECI resource adapter supports only the LocalTransaction interface. As a result, the scope of the transaction is limited to the Resource Manager (that is, the associated connection factory and the specified CICS server). Such Resource Manager local transactions support only one-phase-commit processing. So, if the enterprise bean shown in Figure 8 attempts to access another recoverable resource (for example, a JDBC call to update an IBM DB2® table), an exception occurs when the transaction manager tries to commit both updates.
• If you use a J2EE application server that supports the JCA option of last-resource commit optimization, an interaction using an ECIConnectionFactory class can participate in a global transaction, provided that it is the only one-phase-commit resource in the global transaction.
• The transactions are considered local to the respective application servers.

Two-phase commit between WebSphere Application Server and CICS TS on z/OS

Figure 7 shows a two-phase commit between WebSphere Application Server for the distributed environment, and CICS TS on z/OS (similar to sync level 2 support).

In this topology:

• You use the CICS ECI XA resource adapter to support two-phase-commit global transactions along with CICS Transaction Gateway for z/OS. Hence you can synchronize database updates from both ends.
• One-phase-commit transactions using the CICS ECI resource adapter are also supported. Note that in either case, if you deploy the enterprise bean with a transactional deployment descriptor (for example, a value of REQUIRED), the resulting ECI request to CICS Transaction Server uses the transactional EXCI.
• In this case, both CICS Transaction Gateway and CICS Transaction Server need to be configured to register with Resource Recovery Services (RRS) on z/OS.

Two-phase commit between WebSphere Application Server on z/OS and CICS Transaction Server on z/OS

Figure 8 shows a two-phase commit between WebSphere Application Server on z/OS and CICS TS on z/OS

In Figure 8, Both WebSphere Application Server and CICS TS are configured on the same z/OS machine.

• RRS (Resource Recovery Services) provides the two-phase-commit, an integral part of z/OS. RRS acts as the external transaction coordinator for z/OS in managing the transaction scope between WebSphere Application Server, CICS Transaction Server and other z/OS subsystems, including IBM IMS Transaction Manager (IMS/TM), IMS/DB, DB2 and IBM WebSphere MQ systems.
• Two phase commit processing is supported between CICS Transaction Server and WebSphere Application Server. Hence you can synchronize database updates from both ends.

Back to top

Synchronization between WebSphere MQ and CICS Transaction Server

WebSphere MQ (Message Queue) is IBM’s premier messaging middleware product, which provides an available, reliable, scalable, secure, and maintainable transport for messages with delivery assurance.

WebSphere MQ acts as a resource manager when integrated with CICS TS. CICS TS coordinates the transactions and updates between WebSphere MQ and other resource managers using the CICS adapter for WebSphere MQ.

Synchronizing the start and end of units of work is necessary in a transaction processing environment to safely use transaction processing. This is fully supported by WebSphere MQ for z/OS in CICS, which means that the resource managers cooperate to commit or back out units of work in unison, under the control of CICS TS. Examples of resource managers are DB2, CICS File Control, and WebSphere MQ for z/OS.

In Figure 9:

• You use WebSphere MQ as a resource manager.
• You use WebSphere MQ-CICS for tighter integration with CICS to provide syncpoint support

Back to top

Summary

Synchronization is a very important mechanism to understand when designing business critical applications. In this article we first looked at the importance of synchronization and various methods for synchronization. We saw that, based on the business logic, data updates and the environment, you need to choose the right products to provide an appropriate synchronization mechanism. We then provided the basics of how IBM transaction and messaging middleware products provide synchronization support in various ways when integrated with CICS TS. The intent of this article is to provide guidance on synchronization for architects who design business applications using IBM products.

Resources

Learn

• TXSeries 6.2 Information Center
  
  
• WebSphere MQ documentation
  
  
• CICS Transaction Server documentation
  
  
• CICS Transaction Gateway Javadoc
  
  
• IBM CICS Transaction Gateway Information Center
  
  
• developerworks WebSphere on System z zone
  
  

Get products and technologies

• Evalaute our latest products for modernizing and deploying core System z applications at the IBM Enterprise Modernization Sandbox for System z
  
  

About the authors

Shyam Prakash is a IT Specialist/Test Architect for the IBM TXSeries project, at the India Software Lab. His experience includes development, Level 3 support, and the Lab advocate for IBM TXSeries products. His areas of interest include high-performance computing, cloud computing, transaction processing management and Unix systems.

Mangala is a software engineer in IBM, India Software Labs. She is currently working in TXSeries development team and has expertise in designing and developing middleware applications like TXSeries. Her areas of interest are transaction processing and UNIX systems.

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• Introduction
• Importance of synchronization
• Synchronization methods
• Synchronization between TXSeries and CICS Transaction Server
• Synchronization between WebSphere Application Server and CICS Transaction Server
• Synchronization between WebSphere MQ and CICS Transaction Server
• Summary
• Resources
• About the authors
• Comments

Next steps from IBM

• Try: TXSeries for Multiplatforms
• Webcast: Agile requirements: Collaborative, contextual, and correct
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: TXSeries for Multiplatforms

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers