Ignite Transactions Test
Transactions allows to group multiple cache operations, on one or more keys, into a single atomic transaction. These operations are executed without any other interleaved operations on the specified keys, and either all succeed or all fail. There is no partial execution of the operations. Transactions can be enabled for a specific cache in the cache configuration.
Transaction management is one of the key features of any database, the more robust the transactions management, the better the database maintains the data integrity. Given that Apache Ignite is a distributed and cache based database, it makes transaction management even more difficult and prone to problems. That's the reason it is absolutely important to monitor the cache transactions to be sure that operation initiated re successful. Though Apache Ignite can be relied on to maintain the sanctity of transaction, administrators must ensure that tasks and jobs are succeeding are not blocked because of failed transactions.
This test monitors Apache Ignite cluster to gather transactions related statistics and provide key information to administrators about transactions success rate.
Target of the test : Apache Ignite Server
Agent deploying the test : An internal or external agent
Outputs of the test : One set of results for each Apache Ignite Server
Parameter |
Description |
---|---|
Test period |
How often should the test be executed. |
Host |
Enter the IP address of the Apache Ignite cluster. |
Port |
Enter the port number on which JMX connector listens to incoming connections requests. |
JMX Remote Port |
In this text box, enter the name of a virtual warehouse that needs to be monitored. The JMX connector listens on 8686 by default. If it listens on different port in your environment then specify the same. |
JMX User |
Specify the credentials of the user who is authorized to use JMX. |
JMX Password |
Specify the password for the authorized user. |
Confirm Password |
Confirm the password by retyping it here. |
Measurement |
Description |
Measurement Unit |
Interpretation |
---|---|---|---|
Keys locked on node |
Indicates the total number of key locked on the node i.e. which are under a transaction and cannot be updated. |
Number |
If there are too many keys locked on the node, no other operation can be performed until these keys are released, and at times can lead to deadlock. |
Transactions committed on node |
Indicates the total number of transactions committed on the node ever since the cluster is started. |
Number |
Out of total number of transactions, if the number of rolled back transactions is high, administrators need to investigate why system is not able to complete the transactions. |
Transactions rolled back |
Indicates the total number of transactions which were rolled back ever since the cluster is started. |
Number |
|
Transactions initiated on node |
Indicates the total number of transactions that were initiated on the node ever since the cluster is started. |
Number |
|
Transactions holding lock |
Indicates the total number of open transactions which are still holding lock on at least one of the keys on the node. |
Number |
If there are too many keys locked on the node, no other operation can be performed until these keys are released, and at times can lead to deadlock. |