Browse Prior Art Database

A method for software trace control Disclosure Number: IPCOM000201558D
Publication Date: 2010-Nov-15

Publishing Venue

The Prior Art Database


This invention generally relates to software trace control and particularly relates to tracing a specific execution path of software programs. This invention is primarily based on hierarchical relationship between the transactions (parent transaction) and sub (child) transactions to enable/disable the trace.

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

Page 01 of 18

A method for software trace control

In general when a problem happens, the first (?) step anybody would take in analysis would be: Why problem happened? What is the root cause? What are the contributing factors which might have zoomed the problem?

One of the sources to get started to answer above questions is the historical data of similar problems. Thou this data is useful, it may not help always. Instead if the action leading to the problem itself stores/saves few relevant information then, it will greatly help in problem analysis.

In computer science, this mechanism is widely used in the name of tracing from a program in execution. Typically, a trace is a record of one of the step a program has taken while being executed. A group of such records saved at different instances and places form the program in execution will help greatly in problem analysis. In other words, Software tracing is a specialized use of logging to record information about a program's execution. Currently there are different types of trace mechanisms available that supports features like tracing based on levels (amount of trace records.For ex: entry/exit may flood. Enabling only for error records might be good but not enough for problem analysis), components, hooks, markers and trace points. However there is no support for tracing a particular transaction and a specific instance of a transaction.

For example, in Fig 1 below, shows 3 different execution paths (or 3 different transactions) T1S1S4S5, T2S2S4S5 and T3S3S4S5. Most of the current day traces mechanisms support tracing either all transactions or a subset of transaction, for example S1 or S2 or S3. Tracing all transactions is done by enabling a complete application trace and tracing a subset of a transaction is done by enabling trace at component level. However there is no mechanism, to trace only T1S2S4S5 or only S5 initiated from T1 or a specific instance of T1S1S4S5 when multiple transactions are running.


Page 02 of 18







Fig 1: An Application with 3 transactions

When multiple transactions are running and the problem is specific to one particular transaction then it not required to trace all transactions. For example, Fig 2 shows 4 transactions Balance Enquiry, Cash Deposit, Cash Withdrawal and Transfer. If the problem is specific to DB Update during Balance Enquiry then it would be sufficient to tracing only that execution path, not all transactions.

This invention disclosure generally relates to software trace control and particularly relates to tracing a specific execution path of software programs i.e. a transaction. A Transaction may or may not be a business or database transaction. The current invention only focuses on tracing a transaction or instance of a transaction executed by one ore more software programs run in a single server, multiple process, multi threaded environment. The environment consists of applications communicating using IPC mechanism which supports iden...