After a DML execution in the DB, if a Commit or a Rollback execution is not done properly, it may lead to a delay in transaction processing time in the DB or a problem in the data consistency.
Through the alarm generated in the Real Time Monitoring screen, you can identify the cause of delayed transactions.
(!) Check Results: Lock has been generated in the DB Stat due to increase in the number of transactions being delayed for over 5 seconds in the Real Time screen. Based on the Lock Tree, the transactions are being backed up due to a transaction executing a DML has occupied the TX Lock.
(!) Check Results: You can check the XM_JDBC_NOT_COMMIT_ROLLBACK’s alert details.
(!) Check Results: Double-click the real time alerts history and check the detailed information of the transaction which triggered the Lock, and determine whether there is problem in the logic or not.
(!) Check Results: As a result of source analysis, you can know that in the data delete logic, after executing setAutoCommit(false) for processing a transaction, a commit or a rollback execution has been omitted prior to ending a connection.
As a result of identifying the transaction which had not been committed using the Alert function and doing a source analysis; we have identified the application which has occupied the Lock because it was under the condition where the AutoCommit function was made false and the commit was not called. This problem has been resolved by adding commit to the corresponding application source.