Distributed Transaction Processing
Content
<JSTORM>
Distributed Transaction Processing
중앙대학교 컴퓨터공학과 자바 동호회 JSTORM http://www.jstorm.pe.kr
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Document Information
Document title: Document file name: Revision number: Issued by: Issue Date: Status: Distributed Transaction Processing DTP_김순태_JTS_jstorm_1.0_final.pdf <1.0> <JSTORM> <2001/08/08 > final
Content Information
Audience Abstract 자바 고급 JTS와 JTA 그리고 BEA 턱시도, SonicMQ 등의 여러 Reference Benchmark information 회사 제품들을 비교 조 사, XOpen Group DTP표준 모델 설명,
JSTORM
<2/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Table of Contents
Distributed Transaction................................................................................... 4 Processing....................................................................................................... 4
What Is a Transaction ? .......................................................................................................4 What Are the ACID Properties?..........................................................................................4 “What Is Distributed Transaction Processing?” ..................................................................7 “What Is The Open Group DTP Model?” ...........................................................................8 Application programming interfaces ...................................................................................9 The Open Group model communications..........................................................................11 “What Is Two-Phase Commit?” ........................................................................................12 “Transaction in Tuxedo” ( source : BEA ) ........................................................................13 How the System Tracks Distributed Transaction Processing............................................14 “Transaction in JMS” ( source : SonicMQ )......................................................................15 In Doubt Global Transactions ...........................................................................................17 Sample Code(source: SonicMQ) .......................................................................................18
JSTORM
<3/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Distributed Transaction Processing
What Is a Transaction ?
Procedure for Any Transaction Procedure for Bank Withdrawal Example 1. Verify that a withdrawal will be made 2. Withdraw a specified amount from the account 3. Update the record of the balance of the account
1. Verify the activity to be performed 2. Perform the work of the transaction
3. Create a permanent record of the completed work
* the transaction manager associated with the application program that initiates the transaction is called the coordinator. * The databases involved in the global transaction are called participants.
What Are the ACID Properties?
ACID Properties of BEA Tuxedo Transactions
This Means that . . .
JSTORM
<4/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Property . . . Atomicity A transaction is a discrete unit of work: all constituent operations must either succeed or fail. These operations may include queuing messages, updating databases, and displaying the results of a transaction on a screen. A transaction must either (a) leave the system in a correct state or (b) abort. If a transaction cannot achieve a stable state, it must return to its initial state. The behavior of a transaction is not affected by other transactions being executed simultaneously. A transaction must serialize all access to shared resources and guarantee that concurrent programs do not corrupt each other's operations. The effects of a committed transaction are permanent. Even if the system fails, the changes resulting from a transaction are permanent and durable.
Consistency
Isolation
Durability
Example of a Global Transaction
To associate a service with a global transaction, a client: 1. Calls tpbegin() to begin the transaction 2. Issues a service request 3. Calls tpcommit() to end the transaction
As part of a global transaction, the operation is performed as a single unit of work. 1. client : the CUST_ORDER service is invoked(tpbegin()) 2. server : the server is propagated with the client's transaction 3. server : accessing the order database and enqueuing the order to the shipping queue
Passing the ACID Test: Properties of a Transaction
The characteristics of a transaction are commonly described in terms of the ACID properties, as follows: Atomicity Results of the transaction’s execution are either all committed or all rolled back.
JSTORM
<5/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Consistency A shared resource (such as a database) is transformed from one valid state to another valid state. Isolation The results of a transaction are invisible to other transactions until the transaction is complete. Durability The results of a transaction are permanent and survive future system and media failures. Without the ACID properties, databases could be corrupted, resulting in potentially disastrous results for enterprises. With the Unisys approach, the ACID properties are supported by system software, not left for applications programmers to worry about.
How a Transaction Succeeds or Fails
If . . . Any operation within the transaction fails for any reason Then . . .
• •
The transaction aborts, that is, it terminates abruptly The transaction rolls back, that is, it undoes its own work and restores the state of the enterprise to its pre-transaction state. For example, after an attempt to withdraw money from a bank account fails and is rolled back, the bank account contains the same amount of money it contained before the transaction, and the record of the account balance shows the same amount that it showed before the transaction.
All operations within the transaction succeed
The client commits the transaction. In other words, it formally signals that it is ready to terminate and the effects of the transaction should be preserved: the order database is updated permanently and the order sent to the shipping department is kept as a permanent record in that department's queue.
JSTORM
<6/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
“What Is Distributed Transaction Processing?”
Distributed transaction processing (DTP) is a form of online transaction processing that allows a single transaction to be composed of multiple application programs that access one or more databases on one or more computers across a network. This type of transaction, in which multiple application programs cooperate, is called a distributed transaction.
“Why Are Industry Standards and Models Important?”
For an open, standardized DTP strategy, Unisys has adopted the following standards and models: •The Open Group DTP Model (which includes standard application programming interfaces) •Client/Server Application Model •OSI TP Communications In addition, Unisys products interoperate with systems of other vendors that are based on BEA TUXEDO and Microsoft’s MTS software. These industry standards and models are the key to open, distributed transaction processing. By using DTP systems that adhere to these standards, you can ensure interoperability, portability, and interchangeability. Interoperability Your systems can participate with other systems in global transactions – whether the systems exist in different locations within your enterprise or in other enterprises. Through global transactions, your application programs can access different types of database managers and other components – including those of other vendors.
Portability
Your application programs can be ported across a wide variety of hardware platforms.
Interchangeability
JSTORM
<7/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Your systems can be constructed with hardware and software from different vendors. This gives you the freedom to choose system components based on your needs.
Widespread acceptance
The Open Group DTP model has been widely accepted by major database vendors worldwide, including ORACLE, Sybase, and Informix.
“What Is The Open Group DTP Model?”
The Open Group Distributed Transaction Processing model is an industry standard for DTP systems. It was developed by The Open Group, a consortium of users and vendors who define open systems standards. These standards are described in a set of documents called The Open Group Portability Guide (XPG). The objective of The Open Group DTP model is to define a DTP environment that can accomplish the following: •Process global transactions using heterogeneous components across a network •Consist of hardware and software from different vendors •Contain portable application programs that run on different computers The model specifies components and interfaces between the components.
Components
The Open Group DTP model specifies these components:
Application Program
The program logic developed by applications programmers to perform one or more specific tasks. (Note that an entire application can consist of one or more application programs.)
JSTORM
<8/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Transaction Manager
Vendor-supplied software that coordinates global transactions and ensures database synchronization.
Resource Manager
Vendor-supplied software that manages part of a system’s shared resources, such as databases.
Communications Resource Manager
Vendor-supplied software that serves as a specialized resource manager to support data communication between application programs. The Open Group model xATMI communications resource manager is available today with the Unisys Open Distributed Transaction Processing products.
Application programming interfaces
그림 1>DTP API
The model specifies these application programming interfaces that enable application programs to interact with system components:
AP-RM
JSTORM <9/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
The interface between the application program and the resource manager that allows a resource (such as a database) to be updated. The interface is not specifically defined by The Open Group model. An example is the Structured Query Language (SQL).
TX
The interface between the application program and the transaction manager that enables application programs to begin and end global transactions.
CM
The interface between the application program and the communications resource manager that allows the application program to communicate with other application programs. The client/server interface, the peer-to-peer, and remote procedure call interfaces as defined by The Open Group are available today.
System Interfaces
The model specifies these system interfaces that enable the system components to interact with one another. (Although these interfaces are not visible to programmers, they are important because they allow interchangeability of system components.)
XA
The interface between the resource manager and the transaction manager that enables them to coordinate global transactions. This interface enables a twophase commit capability (described later in this document), which ensures database synchronization.
XA+
The interface between the transaction manager and the communications resource managers that enables them to coordinate transactions between computers in a DTP system.
The Open Group model communications
JSTORM
<10/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
In addition to the interfaces above, systems that implement The Open Group model communicate with each other using the following:
XAP-TP
The interface into OSI TP services is typically used by the communications resource managers to initiate and support communications between local and remote application programs within a DTP system.
OSI TP
The protocol that supports communication between computers in a DTP system. The Open Systems Interconnection (OSI) Transaction Processing (TP) is a communications protocol for transaction processing systems. It was developed by the International Organization for Standardization (ISO) as a machine-independent protocol and has been incorporated into The Open Group DTP model. (Note that the Unisys implementation of OSI TP includes support of OSI, TCP/IP, DCA, and BNA networks.)
“What Is Two-Phase Commit?”
Two-phase commit is the capability that enables you to realize the ultimate benefits of distributed transaction processing. It ensures that all resources, such as databases, are synchronized. Why is this important?
The problem
Consider a situation in which a customer wants to transfer $100 from a savings to a checking account. The transaction involves two databases, which may reside on different computers. The first part of the transaction debits $100 from savings and the second part credits $100 to checking. However, what happens if the second computer fails before the transaction is complete? The $100 would be debited from savings, but would not be credited to checking. The databases are not synchronized, which could lead to disastrous results.
The solution
Two-phase commit is the solution. It ensures that all participating databases are synchronized. Either all updates are made or, in the event of system or
JSTORM
<11/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
component failure, none are made. Two-phase commit guarantees global data integrity and preserves the OLTP ACID properties in a DTP environment. And that is critical for your business and your customers.
Two-Phase Commit-Behind the Scenes
The transaction manager associated with the application program that initiates the transaction is called the coordinator. The databases involved in the global transaction are called participants. With twophase commit, the coordinator orchestrates the synchronization of all participants. The database updates are made in two phases, like this: Phase 1: The coordinator asks all participants if they can guarantee a commit. All participants respond.
Phase 2: The coordinator instructs all participants to commit (if all were ready) or to abort (if even a single participant was not ready). All participants confirm their activity. Phase
그림 2> Two Phase Commit
JSTORM
<12/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
“Transaction in Tuxedo” ( source : BEA )
What Is the BEA Tuxedo Transaction Manager (TM)
Resource Manager (RM) is a data repository, such as a database management system or the Application Queuing Manager, with tools for accessing the data.
Actions Performed by the Transaction Manager
When . . . The application launches a transaction Other processes communicate with the process that launched the transaction The RM is accessed as part of the work of the transaction The Transaction Manager . . . Assigns a global transaction identifier (GTRID) to the transaction Tracks those communication partners
Passes the appropriate GTRID to the RM so the RM can monitor which database records are being accessed for the transaction. Performs a 2-phase commit protocol. Specifically, it (a) contacts communication partners during Phase 1, (b) logs the successful outcome of Phase 1, and (c) contacts partners in Phase 2. Executes a rollback procedure
The application signals that a transaction is to be committed
The application indicates that the transaction is to be aborted A failure occurs
Executes a recovery procedure
How the System Tracks Distributed Transaction Processing
JSTORM <13/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
a local machine involved in a transaction can communicate with a remote machine which may, in turn, communicate with another remote machine. The work of transactions executed in this type of arrangement is referred to as distributed transaction processing.
그림 3>Tuxedo 7.1의 DTP Because the system must constantly maintain enough information about a transaction to be able to roll it back (that is, to restore it to its initial state) at any moment, tracking distributed transaction processing (DTP) can be a complex task. To perform this task successfully, the BEA Tuxedo system stores tracking information about all the participants in a transaction in a dedicated file called a transaction log, or TLOG.
A global transaction is recorded in the transaction log (TLOG) only when it is in the process of being committed. At the end of the first phase of a 2-phase-commit protocol, the TLOG records the reply from the global transaction participants. The existence of a TLOG record indicates that a global transaction should be committed; no TLOG records are written for transactions that are to be rolled back. In the first "pre-commit" phase, each Resource Manager must commit to performing the transaction request. If all parties commit, transaction management performs the second phase: it commits and completes the transaction. If either task fails because of an application or system failure, both tasks fail and the work performed is undone or "rolled back" to its initial state. The TMS that coordinates global transactions uses the TLOG file. Each machine should have its own TLOG.
“Transaction in JMS” ( source : SonicMQ )
Transaction Types
A single SonicMQ application can contain both local and global transactions.
JSTORM
<14/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Local Transaction
A local transaction involves a single resource manager. In SonicMQ, a transaction performed in a session with the transacted parameter set to true is a local transaction.
Global Transaction
A global transaction involves dispersed resources in the transaction. It is often referred to as a distributed transaction. A distributed transaction system typically relies on an external transaction manager to coordinate the participants in a transaction.
Components of Distributed Transactions
Distributed transactions have as many as five components. Each contributes to the distributed transaction processing system by implementing different sets of transaction APIs and functionalities. The Java Transaction Service (JTS) describes these components as follows:
nA
transaction manager provides the services and management functions required to support transaction demarcation, transactional resource management, synchronization, and transaction context propagation. application server (or TP monitor) provides the infrastructure that supports the application run-time environment including transaction state management. An example of such an application server is an EJB server.
n An
nA
resource manager (RM) is an entity that manages data or some other kind of resource through a resource adapter. SonicMQ is a resource manager, implementing a transaction resource interface—the XAResource interface of the Java Transaction API (JTA)—that the transaction manager uses to communicate transaction association, transaction completion, and recovery work. transactional application in an application server environment relies on the application server to provide transaction management support through transaction attribute settings—for example, an application developed using communication resource manager (CRM) supports transaction context propagation and access to the transaction service for incoming and outgoing requests. From the transaction manager’s perspective, the actual
nA
nA
JSTORM
<15/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
implementation of the transaction services does not need to be exposed; only high-level interfaces need to be defined to allow transaction demarcation, resource enlistment, synchronization, and recovery process to be driven by the users of the transaction services.
그림 4>Enlistment of a Second RM to a Distributed Transaction
그림 5>Distributed Transaction with Multiple Transaction Managers
In Doubt Global Transactions
If a global transaction succeeded in phase one of the two-phase commit, the physical connections could fail such that part of the global transaction is
JSTORM
<16/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
recorded and part of it is indeterminate. The commitment might have been executed but failed before notifying the TM.
그림 6>In-Doubt Transaction During Two-Phase Commit
Sample Code(source: SonicMQ)
public void onMessage(Message message) { try { InitialContext ctx = new InitialContext(); TopicConnectionFactory tcf = (TopicConnectionFactory)ctx.lookup("XATopicConnectionFactory"); TopicConnection tc = tcf.createTopicConnection(); TopicSession ts = tc.createTopicSession(false, TopicSession.AUTO_ACKNOWLEDGE);
Topic topic = ts.createTopic(“SampleT1"); TopicPublisher pub = ts.createPublisher( topic ); TextMessage msgt = ts.createTextMessage(); pub.publish(msgt); tc.close();
QueueConnectionFactory qcf = (QueueConnectionFactory)ctx.lookup("XAQueueConnectionFactory"); QueueConnection qc = qcf.createQueueConnection(); QueueSession qs = qc.createQueueSession(false,
JSTORM
<17/19>
Distributed Transaction Processing Revision: <1.0>
QueueSession.AUTO_ACKNOWLEDGE);
Issued by: <김순태> <2002/01/30>
Queue queue = qs.createQueue("SampleQ2"); QueueSender sender = qs.createSender( queue ); TextMessage msgq = qs.createTextMessage(); sender.send(msgq); qc.close();
// ****************** Oracle Connection ******************* DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/tebsource"); java.sql.Connection dbConn = ds.getConnection(); Statement s = dbConn.createStatement(); s.executeUpdate("insert into sonic_artist values('100','Bob Smith')"); dbConn.close(); } catch(Exception e) { e.printStackTrace(); } } //onMessage()
그림 7>SonicMQ Integrated with an Application Server
JSTORM
<18/19>
Distributed Transaction Processing
중앙대학교 컴퓨터공학과 자바 동호회 JSTORM http://www.jstorm.pe.kr
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Document Information
Document title: Document file name: Revision number: Issued by: Issue Date: Status: Distributed Transaction Processing DTP_김순태_JTS_jstorm_1.0_final.pdf <1.0> <JSTORM> <2001/08/08 > final
Content Information
Audience Abstract 자바 고급 JTS와 JTA 그리고 BEA 턱시도, SonicMQ 등의 여러 Reference Benchmark information 회사 제품들을 비교 조 사, XOpen Group DTP표준 모델 설명,
JSTORM
<2/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Table of Contents
Distributed Transaction................................................................................... 4 Processing....................................................................................................... 4
What Is a Transaction ? .......................................................................................................4 What Are the ACID Properties?..........................................................................................4 “What Is Distributed Transaction Processing?” ..................................................................7 “What Is The Open Group DTP Model?” ...........................................................................8 Application programming interfaces ...................................................................................9 The Open Group model communications..........................................................................11 “What Is Two-Phase Commit?” ........................................................................................12 “Transaction in Tuxedo” ( source : BEA ) ........................................................................13 How the System Tracks Distributed Transaction Processing............................................14 “Transaction in JMS” ( source : SonicMQ )......................................................................15 In Doubt Global Transactions ...........................................................................................17 Sample Code(source: SonicMQ) .......................................................................................18
JSTORM
<3/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Distributed Transaction Processing
What Is a Transaction ?
Procedure for Any Transaction Procedure for Bank Withdrawal Example 1. Verify that a withdrawal will be made 2. Withdraw a specified amount from the account 3. Update the record of the balance of the account
1. Verify the activity to be performed 2. Perform the work of the transaction
3. Create a permanent record of the completed work
* the transaction manager associated with the application program that initiates the transaction is called the coordinator. * The databases involved in the global transaction are called participants.
What Are the ACID Properties?
ACID Properties of BEA Tuxedo Transactions
This Means that . . .
JSTORM
<4/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Property . . . Atomicity A transaction is a discrete unit of work: all constituent operations must either succeed or fail. These operations may include queuing messages, updating databases, and displaying the results of a transaction on a screen. A transaction must either (a) leave the system in a correct state or (b) abort. If a transaction cannot achieve a stable state, it must return to its initial state. The behavior of a transaction is not affected by other transactions being executed simultaneously. A transaction must serialize all access to shared resources and guarantee that concurrent programs do not corrupt each other's operations. The effects of a committed transaction are permanent. Even if the system fails, the changes resulting from a transaction are permanent and durable.
Consistency
Isolation
Durability
Example of a Global Transaction
To associate a service with a global transaction, a client: 1. Calls tpbegin() to begin the transaction 2. Issues a service request 3. Calls tpcommit() to end the transaction
As part of a global transaction, the operation is performed as a single unit of work. 1. client : the CUST_ORDER service is invoked(tpbegin()) 2. server : the server is propagated with the client's transaction 3. server : accessing the order database and enqueuing the order to the shipping queue
Passing the ACID Test: Properties of a Transaction
The characteristics of a transaction are commonly described in terms of the ACID properties, as follows: Atomicity Results of the transaction’s execution are either all committed or all rolled back.
JSTORM
<5/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Consistency A shared resource (such as a database) is transformed from one valid state to another valid state. Isolation The results of a transaction are invisible to other transactions until the transaction is complete. Durability The results of a transaction are permanent and survive future system and media failures. Without the ACID properties, databases could be corrupted, resulting in potentially disastrous results for enterprises. With the Unisys approach, the ACID properties are supported by system software, not left for applications programmers to worry about.
How a Transaction Succeeds or Fails
If . . . Any operation within the transaction fails for any reason Then . . .
• •
The transaction aborts, that is, it terminates abruptly The transaction rolls back, that is, it undoes its own work and restores the state of the enterprise to its pre-transaction state. For example, after an attempt to withdraw money from a bank account fails and is rolled back, the bank account contains the same amount of money it contained before the transaction, and the record of the account balance shows the same amount that it showed before the transaction.
All operations within the transaction succeed
The client commits the transaction. In other words, it formally signals that it is ready to terminate and the effects of the transaction should be preserved: the order database is updated permanently and the order sent to the shipping department is kept as a permanent record in that department's queue.
JSTORM
<6/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
“What Is Distributed Transaction Processing?”
Distributed transaction processing (DTP) is a form of online transaction processing that allows a single transaction to be composed of multiple application programs that access one or more databases on one or more computers across a network. This type of transaction, in which multiple application programs cooperate, is called a distributed transaction.
“Why Are Industry Standards and Models Important?”
For an open, standardized DTP strategy, Unisys has adopted the following standards and models: •The Open Group DTP Model (which includes standard application programming interfaces) •Client/Server Application Model •OSI TP Communications In addition, Unisys products interoperate with systems of other vendors that are based on BEA TUXEDO and Microsoft’s MTS software. These industry standards and models are the key to open, distributed transaction processing. By using DTP systems that adhere to these standards, you can ensure interoperability, portability, and interchangeability. Interoperability Your systems can participate with other systems in global transactions – whether the systems exist in different locations within your enterprise or in other enterprises. Through global transactions, your application programs can access different types of database managers and other components – including those of other vendors.
Portability
Your application programs can be ported across a wide variety of hardware platforms.
Interchangeability
JSTORM
<7/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Your systems can be constructed with hardware and software from different vendors. This gives you the freedom to choose system components based on your needs.
Widespread acceptance
The Open Group DTP model has been widely accepted by major database vendors worldwide, including ORACLE, Sybase, and Informix.
“What Is The Open Group DTP Model?”
The Open Group Distributed Transaction Processing model is an industry standard for DTP systems. It was developed by The Open Group, a consortium of users and vendors who define open systems standards. These standards are described in a set of documents called The Open Group Portability Guide (XPG). The objective of The Open Group DTP model is to define a DTP environment that can accomplish the following: •Process global transactions using heterogeneous components across a network •Consist of hardware and software from different vendors •Contain portable application programs that run on different computers The model specifies components and interfaces between the components.
Components
The Open Group DTP model specifies these components:
Application Program
The program logic developed by applications programmers to perform one or more specific tasks. (Note that an entire application can consist of one or more application programs.)
JSTORM
<8/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Transaction Manager
Vendor-supplied software that coordinates global transactions and ensures database synchronization.
Resource Manager
Vendor-supplied software that manages part of a system’s shared resources, such as databases.
Communications Resource Manager
Vendor-supplied software that serves as a specialized resource manager to support data communication between application programs. The Open Group model xATMI communications resource manager is available today with the Unisys Open Distributed Transaction Processing products.
Application programming interfaces
그림 1>DTP API
The model specifies these application programming interfaces that enable application programs to interact with system components:
AP-RM
JSTORM <9/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
The interface between the application program and the resource manager that allows a resource (such as a database) to be updated. The interface is not specifically defined by The Open Group model. An example is the Structured Query Language (SQL).
TX
The interface between the application program and the transaction manager that enables application programs to begin and end global transactions.
CM
The interface between the application program and the communications resource manager that allows the application program to communicate with other application programs. The client/server interface, the peer-to-peer, and remote procedure call interfaces as defined by The Open Group are available today.
System Interfaces
The model specifies these system interfaces that enable the system components to interact with one another. (Although these interfaces are not visible to programmers, they are important because they allow interchangeability of system components.)
XA
The interface between the resource manager and the transaction manager that enables them to coordinate global transactions. This interface enables a twophase commit capability (described later in this document), which ensures database synchronization.
XA+
The interface between the transaction manager and the communications resource managers that enables them to coordinate transactions between computers in a DTP system.
The Open Group model communications
JSTORM
<10/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
In addition to the interfaces above, systems that implement The Open Group model communicate with each other using the following:
XAP-TP
The interface into OSI TP services is typically used by the communications resource managers to initiate and support communications between local and remote application programs within a DTP system.
OSI TP
The protocol that supports communication between computers in a DTP system. The Open Systems Interconnection (OSI) Transaction Processing (TP) is a communications protocol for transaction processing systems. It was developed by the International Organization for Standardization (ISO) as a machine-independent protocol and has been incorporated into The Open Group DTP model. (Note that the Unisys implementation of OSI TP includes support of OSI, TCP/IP, DCA, and BNA networks.)
“What Is Two-Phase Commit?”
Two-phase commit is the capability that enables you to realize the ultimate benefits of distributed transaction processing. It ensures that all resources, such as databases, are synchronized. Why is this important?
The problem
Consider a situation in which a customer wants to transfer $100 from a savings to a checking account. The transaction involves two databases, which may reside on different computers. The first part of the transaction debits $100 from savings and the second part credits $100 to checking. However, what happens if the second computer fails before the transaction is complete? The $100 would be debited from savings, but would not be credited to checking. The databases are not synchronized, which could lead to disastrous results.
The solution
Two-phase commit is the solution. It ensures that all participating databases are synchronized. Either all updates are made or, in the event of system or
JSTORM
<11/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
component failure, none are made. Two-phase commit guarantees global data integrity and preserves the OLTP ACID properties in a DTP environment. And that is critical for your business and your customers.
Two-Phase Commit-Behind the Scenes
The transaction manager associated with the application program that initiates the transaction is called the coordinator. The databases involved in the global transaction are called participants. With twophase commit, the coordinator orchestrates the synchronization of all participants. The database updates are made in two phases, like this: Phase 1: The coordinator asks all participants if they can guarantee a commit. All participants respond.
Phase 2: The coordinator instructs all participants to commit (if all were ready) or to abort (if even a single participant was not ready). All participants confirm their activity. Phase
그림 2> Two Phase Commit
JSTORM
<12/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
“Transaction in Tuxedo” ( source : BEA )
What Is the BEA Tuxedo Transaction Manager (TM)
Resource Manager (RM) is a data repository, such as a database management system or the Application Queuing Manager, with tools for accessing the data.
Actions Performed by the Transaction Manager
When . . . The application launches a transaction Other processes communicate with the process that launched the transaction The RM is accessed as part of the work of the transaction The Transaction Manager . . . Assigns a global transaction identifier (GTRID) to the transaction Tracks those communication partners
Passes the appropriate GTRID to the RM so the RM can monitor which database records are being accessed for the transaction. Performs a 2-phase commit protocol. Specifically, it (a) contacts communication partners during Phase 1, (b) logs the successful outcome of Phase 1, and (c) contacts partners in Phase 2. Executes a rollback procedure
The application signals that a transaction is to be committed
The application indicates that the transaction is to be aborted A failure occurs
Executes a recovery procedure
How the System Tracks Distributed Transaction Processing
JSTORM <13/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
a local machine involved in a transaction can communicate with a remote machine which may, in turn, communicate with another remote machine. The work of transactions executed in this type of arrangement is referred to as distributed transaction processing.
그림 3>Tuxedo 7.1의 DTP Because the system must constantly maintain enough information about a transaction to be able to roll it back (that is, to restore it to its initial state) at any moment, tracking distributed transaction processing (DTP) can be a complex task. To perform this task successfully, the BEA Tuxedo system stores tracking information about all the participants in a transaction in a dedicated file called a transaction log, or TLOG.
A global transaction is recorded in the transaction log (TLOG) only when it is in the process of being committed. At the end of the first phase of a 2-phase-commit protocol, the TLOG records the reply from the global transaction participants. The existence of a TLOG record indicates that a global transaction should be committed; no TLOG records are written for transactions that are to be rolled back. In the first "pre-commit" phase, each Resource Manager must commit to performing the transaction request. If all parties commit, transaction management performs the second phase: it commits and completes the transaction. If either task fails because of an application or system failure, both tasks fail and the work performed is undone or "rolled back" to its initial state. The TMS that coordinates global transactions uses the TLOG file. Each machine should have its own TLOG.
“Transaction in JMS” ( source : SonicMQ )
Transaction Types
A single SonicMQ application can contain both local and global transactions.
JSTORM
<14/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
Local Transaction
A local transaction involves a single resource manager. In SonicMQ, a transaction performed in a session with the transacted parameter set to true is a local transaction.
Global Transaction
A global transaction involves dispersed resources in the transaction. It is often referred to as a distributed transaction. A distributed transaction system typically relies on an external transaction manager to coordinate the participants in a transaction.
Components of Distributed Transactions
Distributed transactions have as many as five components. Each contributes to the distributed transaction processing system by implementing different sets of transaction APIs and functionalities. The Java Transaction Service (JTS) describes these components as follows:
nA
transaction manager provides the services and management functions required to support transaction demarcation, transactional resource management, synchronization, and transaction context propagation. application server (or TP monitor) provides the infrastructure that supports the application run-time environment including transaction state management. An example of such an application server is an EJB server.
n An
nA
resource manager (RM) is an entity that manages data or some other kind of resource through a resource adapter. SonicMQ is a resource manager, implementing a transaction resource interface—the XAResource interface of the Java Transaction API (JTA)—that the transaction manager uses to communicate transaction association, transaction completion, and recovery work. transactional application in an application server environment relies on the application server to provide transaction management support through transaction attribute settings—for example, an application developed using communication resource manager (CRM) supports transaction context propagation and access to the transaction service for incoming and outgoing requests. From the transaction manager’s perspective, the actual
nA
nA
JSTORM
<15/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
implementation of the transaction services does not need to be exposed; only high-level interfaces need to be defined to allow transaction demarcation, resource enlistment, synchronization, and recovery process to be driven by the users of the transaction services.
그림 4>Enlistment of a Second RM to a Distributed Transaction
그림 5>Distributed Transaction with Multiple Transaction Managers
In Doubt Global Transactions
If a global transaction succeeded in phase one of the two-phase commit, the physical connections could fail such that part of the global transaction is
JSTORM
<16/19>
Distributed Transaction Processing Revision: <1.0>
Issued by: <김순태> <2002/01/30>
recorded and part of it is indeterminate. The commitment might have been executed but failed before notifying the TM.
그림 6>In-Doubt Transaction During Two-Phase Commit
Sample Code(source: SonicMQ)
public void onMessage(Message message) { try { InitialContext ctx = new InitialContext(); TopicConnectionFactory tcf = (TopicConnectionFactory)ctx.lookup("XATopicConnectionFactory"); TopicConnection tc = tcf.createTopicConnection(); TopicSession ts = tc.createTopicSession(false, TopicSession.AUTO_ACKNOWLEDGE);
Topic topic = ts.createTopic(“SampleT1"); TopicPublisher pub = ts.createPublisher( topic ); TextMessage msgt = ts.createTextMessage(); pub.publish(msgt); tc.close();
QueueConnectionFactory qcf = (QueueConnectionFactory)ctx.lookup("XAQueueConnectionFactory"); QueueConnection qc = qcf.createQueueConnection(); QueueSession qs = qc.createQueueSession(false,
JSTORM
<17/19>
Distributed Transaction Processing Revision: <1.0>
QueueSession.AUTO_ACKNOWLEDGE);
Issued by: <김순태> <2002/01/30>
Queue queue = qs.createQueue("SampleQ2"); QueueSender sender = qs.createSender( queue ); TextMessage msgq = qs.createTextMessage(); sender.send(msgq); qc.close();
// ****************** Oracle Connection ******************* DataSource ds = (DataSource)ctx.lookup("java:comp/env/jdbc/tebsource"); java.sql.Connection dbConn = ds.getConnection(); Statement s = dbConn.createStatement(); s.executeUpdate("insert into sonic_artist values('100','Bob Smith')"); dbConn.close(); } catch(Exception e) { e.printStackTrace(); } } //onMessage()
그림 7>SonicMQ Integrated with an Application Server
JSTORM
<18/19>
