eG Monitoring
 

Measures reported by EgJbTransactionTest

A transaction is a unit of work containing one or more operations involving one or more shared resources having ACID properties. ACID is an acronym for atomicity, consistency, isolation and durability, the four important properties of transactions. These terms are defined below in detail:

  • Atomicity: A transaction must be atomic. This means that either all the work done in the transaction must be performed, or none of it must be performed. Doing part of a transaction is not allowed.
  • Consistency: When a transaction is completed, the system must be in a stable and consistent condition.
  • Isolation: Different transactions must be isolated from each other. This means that the partial work done in one transaction is not visible to other transactions until the transaction is committed, and that each process in a multi-user system can be programmed as if it was the only process accessing the system.
  • Durability: The changes made during a transaction are made persistent when it is committed. When a transaction is committed, its changes will not be lost, even if the server crashes afterwards.

Transactions are performed using the Java transaction API. The Java Transaction API consists of three elements: a high-level application transaction demarcation interface, a high-level transaction manager interface intended for application server, and a standard Java mapping of the X/Open XA protocol intended for transactional resource manager. All of the JTA classes and interfaces occur within the javax.transaction package, and the corresponding JBossJTA implementations within the com.arjuna.ats.jta package. The UserTransaction interface provides applications with the ability to control transaction boundaries. It has methods for beginning, committing, and rolling back top-level transactions. The TransactionManager interface allows the application server to control transaction boundaries on behalf of the application being managed.

The Transaction Manager maintains the transaction context association with threads as part of its internal data structure. A thread's transaction context is either null or it refers to a specific global transaction. Multiple threads may be associated with the same global transaction.

Each transaction context is encapsulated by a Transaction object, which can be used to perform operations which are specific to the target transaction, regardless of the calling thread’s transaction context. Sometimes, there may be too many transactions being performed on the target application server and administrators may lose count on the number of transactions of each type. This is exactly where the EgJbTransactionTest test helps!

This test measures the transaction activity performed by the JBoss AS/EAP server. Using this test, administrators can easily track the numerical statistics of each transaction type and identify which type of transaction is executed too often on the target JBoss AS/EAP server.

The measures made by this test are as follows:

Measurement Description Measurement Unit Interpretation
Number_trans Indicates the number of transactions on this server. Number This measure is a good indicator of the load on the server.
Abort_trans Indicates the total number of transactions that were aborted i.e., interrupted in this server during the last measurement period. Number  
Appl_trans_rollback Indicates the number of transactions that were rolled back due to application errors during the last measurement period. Number  
Commited_trans Indicates the number of transactions that were committed to be processed by the Transaction manager during the last measurement period. Number If the number of transactions that are being committed is very high, it signifies load on the server. It might be caused when some locked transactions are released suddenly.
Heuristics_trans Indicates the number of transactions that were terminated with heuristic outcome during the last measurement period. Number A heuristic completion (or heuristic decision) occurs when a resource makes a unilateral decision during the completion stage of a distributed transaction to commit or rollback updates. This can leave distributed data in an indeterminate state. Network failures or resource timeouts are possible causes for heuristic completion. In the event of an heuristic completion, one of the following heuristic outcome exceptions may be thrown:

HeuristicRollback—one resource participating in a transaction decided to autonomously rollback its work, even though it agreed to prepare itself and wait for a commit decision. If the Transaction Manager decided to commit the transaction, the resource's heuristic rollback decision was incorrect, and might lead to an inconsistent outcome since other branches of the transaction were committed.

HeuristicCommit—one resource participating in a transaction decided to autonomously commit its work, even though it agreed to prepare itself and wait for a commit decision. If the Transaction Manager decided to rollback the transaction, the resource's heuristic commit decision was incorrect, and might lead to an inconsistent outcome since other branches of the transaction were rolled back.

HeuristicMixed—the Transaction Manager is aware that a transaction resulted in a mixed outcome, where some participating resources committed and some rolled back. The underlying cause was most likely heuristic rollback or heuristic commit decisions made by one or more of the participating resources.

HeuristicHazard—the Transaction Manager is aware that a transaction might have resulted in a mixed outcome, where some participating resources committed and some rolled back. But system or resource failures make it impossible to know for sure whether a Heuristic Mixed outcome definitely occurred. The underlying cause was most likely heuristic rollback or heuristic commit decisions made by one or more of the participating resources.
Inflight_trans Indicates the number of transactions that have begun but are yet to be terminated during the last measurement period. Number A significantly high value may denote a load on the server. This may indicate that specific transactions are taking too long to process requests.
Nested_trans Indicates the number of nested i.e., sub transactions that were created during the last measurement period. Number  
Resource_trans_rollback Indicates the number of transactions that rolled back due to resource failure during the last measurement period. Number A high value indicates a problem with the application or with some other dependent servers (e.g. Database).
Timedout_trans Indicates the number of transactions that rolled back due to timeout during the last measurement period. Number A steady increase in the value of this measure could be due to the problem with the application or with some other dependent server like the database.