Patent Application
20080052678
The novel features believed characteristic of the invention are set forth in the appended claims. The invention itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying drawings, wherein:
Referring to
Referring further to
An operating system runs on processor 102 and is used to coordinate and provide control of various components within data processing system 100 shown in
Referring to
Transactions A-D respectively correspond to components of the software system, and each transaction is carried out as its corresponding software component is traversed during execution of the software system programs. Moreover, each of these corresponding software components is of a type that will be recognized by a currently available transaction monitoring system, such as TCAM, as described above. As stated previously, TCAM is able to recognize standard Java interfaces such as Servlets, EJBs, JDBC and RMI. Transactions associated with these types of components tend to be critical parts of an over-all transaction or procedure such as procedure 200. Accordingly, a first step in an embodiment of the invention is to operate a transaction monitoring system or probe, such as TCAM or the like, to detect or recognize the software components corresponding to transactions A-D. The monitoring system is able to model these transactions and can provide a graphical view thereof, such as the view shown by
A representation such as
As used herein, the term “hidden” software component is defined to mean all software components, whether defined by the user, the operating system/middleware or other non-user code, that are not recognized by currently available transaction monitoring systems such as TCAM. It is to be emphasized that a hidden or unrecognized software component may be a major source of delay or other unwanted effect, when the software system is used to implement procedure 200. Accordingly, as a further step in an embodiment of the invention, a more flexible mechanism is provided to recognize or detect user defined and other hidden or initially unknown software components, and to monitor and model them.
Referring to
Similarly, the runtime system is used to detect or recognize previously hidden software components corresponding to transactions B1 and B2, between transactions B and C, and to transaction B3 between transactions B and D. These software components and their corresponding transactions were previously hidden, since they could not be recognized by currently available transaction monitoring systems. By annotating procedure 200 with the additional transactions of
It is clearly beneficial to discover and provide annotation for initially hidden transactions such as A1-A2 and B1-B3. For example, a user may thereby be able to determine that transactions involving component A1 are always slow, while transactions that do not involve A1 execute quickly. By making the user aware of transaction A1 and characteristics of its corresponding software component, the user would realize that transaction A1 was the source of the delay problem, rather than A or B being the source of the problem.
Referring to
Step 404 of
Following step 402, a decision should be made as to whether more detailed information should be collected, such as information pertaining to the intermediary transactions A1-A2 and B1-B3 shown in
Step 406 pertains to execution of software system programs that contain software components lying between parent transactions and each of their subtransactions. As described above, a transaction A-D that is immediately followed in the A-D sequence by another transaction is the parent of the immediately following transaction. Conversely, the following transaction is a subtransaction of the parent transaction. Thus, as execution step 406 is carried out, all software components between a parent transaction and a subtransaction are traversed by the execution.
In accordance with step 408, context information is stored and generated, as the software between each parent and its subtransaction is executed. This may be carried out by means of the transaction monitoring probe, using a method such as the following:
The startProbe records context information as the execution proceeds from the parent to the subtransaction, and it starts a timer to record the beginning of the transaction time. The endProbe method stops the timer to record the end of such transaction time. If the parent selected at the getParent of the above method is transaction A, the context information stored during the method will include the stack trace between transactions A and B. The stack trace will identify all calls between A and B, as the software therebetween is being executed. Accordingly, the presence of the software components corresponding to A1 and A2, lying between transactions A and B, will be indicated by the stored CONTEXT INFORMATION.
Referring further to
The above method uses Exception e=new Exception to contain the stack trace. If the parent is transaction A, the stack trace would show the path followed in proceeding from transaction A to transaction B. Thus, the trace would include the software components corresponding to transactions A1 and A2. Thus, the software components would be identified as children of transaction A, in accordance with step 414, and A1 and A2 would be inserted between transactions A and B, as shown by
Following step 414, it is necessary to determine whether or not any further transaction is to be selected for analysis as a subtransaction, in order to determine if there are any user defined or other hidden software components between it and its parent. This determination is indicated as step 416. If the conclusion of step 416 is a NO, the process of
For many applications, it would be preferable to carry out steps 410, 412 and 414 for only some, and not all, of the subtransactions of a procedure 200. As stated above, this practice would avoid excessive overhead.
The invention can take the form of an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the invention is implemented in software, which includes but is not limited to firmware, resident software or microcode.
Furthermore, the invention can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any tangible apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.
The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD.
A data processing system suitable for storing and/or executing program code will include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories which provide temporary storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.
Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the system either directly or through intervening I/O controllers.
Network adapters may also be coupled to the system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modem and Ethernet cards are just a few of the currently available types of network adapters.
The description of the present invention has been presented for purposes of illustration and description, and is not intended to be exhaustive or limited to the invention in the form disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art. The embodiment was chosen and described in order to best explain the principles of the invention, the practical application, and to enable others of ordinary skill in the art to understand the invention for various embodiments with various modifications as are suited to the particular use contemplated.
