JBoss Transactions Test

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 JBoss Transactions test helps!

This test measures the transaction activity performed by the WildFly JBoss 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 WildFly JBoss server.

Target of the test : A WildFly JBoss server

Agent deploying the test : An internal agent

Outputs of the test : One set of results for the target WildFly JBoss server that is to be monitored

Configurable parameters for the test
  1. TEST PERIOD - How often should the test be executed
  2. Host – The host for which the test is to be configured
  3. port– The port at which the specified HOSTlistens. By default, this is 9990.
  4. SSLIf the WildFly JBoss server being monitored is an SSL-enabled server, then set the sslflag to Yes. If not, then set the sslflag to No.
  5. IS JBOSS RUNNING IN DOMAIN MODE?– Specify whether the server to be monitored is currently running in DOMAIN MODE or not. By default, this flag is set to No which implies that the server is currently running in STANDALONE MODE. If you have started the target JBoss server using the default web profile configuration in domain mode i.e, if you have executed the ./domain.sh command from the <JBoss_INSTALL_DIR>/bin directory, then specify Yes against this flag.
  6. JBOSS HOST NAME – Specify whether the target server to be monitored is a master or a slave in a JBoss cluster. By default, none will be specified here which implies that the target JBoss server is a standalone server. Refer to Identifying the host name and server instance name of the WildFly JBoss server running in Domain mode to know how to identify whether the target server is a master or slave in your environment.
  7. JBOSS SERVER INSTANCE NAME– Specify the name of the server instance that is to be monitored. By default, none will be specified here. Refer to Identifying the host name and server instance name of the WildFly JBoss server running in Domain mode to identify the name of the server instance that is to be monitored. 
  8. MANAGEMENT USER and MANAGEMENT PASSWORD– Specify the credentials of the user who is authorized to access the management console of the target JBoss server. To create a new user, refer to Creating a new management user in the WildFly JBoss server of this document.
  9. confirm password– Confirm the MANAGEMENT PASSWORD by retyping it here.
Measures made by the test:
Measurement Description Measurement Unit Interpretation

Number of transactions:

Indicates the number of transactions on this server.

Number

This measure is a good indicator of the load on the server.

Aborted transactions:

Indicates the total number of transactions that were aborted i.e., interrupted in this server during the last measurement period.

Number

 

Application transactions rolled back:

Indicates the number of transactions that were rolled back due to application errors during the last measurement period.

Number

 

Committed transactions:

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 transactions:

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 transactions:

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 transactions:

Indicates the number of nested i.e., sub transactions that were created during the last measurement period.

Number

 

Resource transactions rolled back:

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).

Timed-out transactions:

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.