Browse Prior Art Database

COM+ transaction simulator for testing XA loosely coupled transactions with various .NET data providers

IP.com Disclosure Number: IPCOM000124733D
Original Publication Date: 2005-May-04
Included in the Prior Art Database: 2005-May-04
Document File: 5 page(s) / 35K

Publishing Venue

IBM

Abstract

A program is disclosed that generates and drives random XA Loosely Coupled Transactions (LCT) to test the XA LCT functionality of various Relational DataBase Management Systems (RDBMS) using Microsoft COM+* as a transaction manager and Microsoft ADO.NET* as a database access interface. This application uses various .NET data managed providers such as IBM DB2 .NET data provider, Microsoft OLEDB .NET data provider*, Microsoft ODBC .NET data provider*, and Microsoft Sqlclient*, to stress test various resource managers such as IBM DB2 on various platforms and Microsoft SQLServer* on Windows* in a distributed environment.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 27% of the total text.

Page 1 of 5

COM+ transaction simulator for testing XA loosely coupled transactions with various
.NET data providers

1. Introduction

XA distributed transaction process is an important feature of modern relational database management systems. An XA distributed transaction normally involves an XA compliant transaction manager/coordinator such as IBM ® WebSphere ® , BEA Weblogic, and Microsoft COM+, and a few resource managers such as IBM DB2 ® , Oracle, and Microsoft SQL Server. Combined these form a distributed computing environment and are common in database applications. XA loosely coupled transaction (LCT) belongs to XA distributed transaction. It makes multiple site updates more efficient since it allows multiple transaction branches of the same global transaction to share lock resources on the participating RDBMSs. Due to the complexities of a distributed computing environment, testing of XA LCT functionality is a big challenge to both the transaction manager vendors and the resource manager vendors.

   This COM+ transaction simulator named BCom was designed to address the need of testing XA loosely coupled transactions with various .NET data providers (DB2, OLEDB, ODBC, SQLclient) in a distributed computing environment which involves COM+ and various RDBMS such as IBM DB2 Universal Database for different platforms (Unix, Windows, z/OS ® , iSeries), Microsoft SQLServer, and Oracle, etc. It is a multiple thread application targeting the stress testing of both transaction managers and resource managers. The design of the testing logic is not specific to Microsoft COM+ and ADO.NET. It can be easily implemented using other programming languages to support various combinations of transaction managers and resource managers.

The key features of the application:
(1). Simulate an eCommerce bank, randomly generate and drive XA loosely couple transactions with multiple threads to stress both the resource managers and the transaction manager. An XA loosely coupled transaction normally consists of a few transaction branches initiated in more than one COM+ object to access one or more databases. The banking transactions include Open Branch, Add Customer, Open Account, Close Account, Deposit, Withdraw, Transfer Fund, and Query Account, etc. The eCommerce bank is simulated by conducting the banking transactions in a disconnected distributed environment such as the Internet using ADO.NET disconnected Dataset update technologies. Other than this, the application also supports various real time on line banking transactions.
(2). Randomly commit and rollback transactions in LCT branches to trigger Two Phase Commit process and implement logic to check data consistency.
(3). Support multiple processes and multiple threads stress run with optional iteration/infinite loop. An iteration run means that a thread executes a specified number of transactions. An infinite run means that a thread runs forever unless it hits a fatal error. To support an infinite run, the worklo...