Browse Prior Art Database

Distributed transaction processing Trace collecting

IP.com Disclosure Number: IPCOM000240604D
Publication Date: 2015-Feb-12
Document File: 3 page(s) / 65K

Publishing Venue

The IP.com Prior Art Database

Abstract

The article introduces a new approach to collect the trace for a distributed transaction by propagating the trace setting within the transaction flow, and recording the trace with a same format and most importantly into a same destination in sequence.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 34% of the total text.

Page 01 of 3

Distributed transaction processing Trace collecting

Transaction Processing (TP) system is widely used nowadays and is a key system to support mission critical business around the world. In TP system, it's very common that an application will distribute its work flow among multi-regions. For example, A, B and C are three tasks to make up adistributed transaction

which run in different processing regions. Task A attaches B and then B attaches C as a scenario. The data transmission among A, B and C is based on some application level communicating protocol, and there must be a UOW (Unit of Work) ID being used to keep the data consistency.

This kind of architecture is widely used which can largely increaseintegrated performance in TP system. But the relatively complicated communication implement sometimes makes the problem determination a headache. Atpresent, engineers have to diagnose the problem bygoing through the system traces of all the processing regions one by one. As the system trace is stored by each processing region and usually contains mixed trace records of other unrelated transaction trace, it's hard for engineers to distinguish and sort a specific distributed transaction work flow. It usually can be done by using distributed Unit of Work (UOW) ID and also the timestamps, while it always needs big effortas well as plentiful experience. Sometimes the processing regions have different trace settings, e.g. some may collect the trace for one system component, others may not. So the engineers cannot always get enough trace information.

The existing solutions for distributed application maintenance mainly focus on how to get the high level records in each task during run-time. The main methods currently, and their limitations are:
1. Transaction tracking in TP system. It provides the capability to identify the relationships between tasks in an application as theyflow across computing node. However, it only shows what region and what task have problem, but not tell you why, how and where this task is abnormal. It is like a higher level record collection which is not such useful for distributed application problem determination.

2. Transaction monitor in TP system. It focus on detecting the exception of transaction system like slow response time and reaching maximum tasks unexpectedly. It can only tell which task is abnormal, while it can not provide the whole work flowof transactions running across regions.

This article introduces a novel approach to easily generate the transaction trace for one specific distributed application work flow. The mechanism behind can integrate distributed transaction trace together in sequence, so it would be really easy to go through the flow of distributed transaction and spot where any exception takes place. For example, A, B and C are three tasks to make up a distributed transaction which run in different processing regions. Task A attaches B and then B attaches C as a scenario. A can be set wit...