Responsible for most of the work related to monitoring and logging transaction state. This class is notified via a
when a key
occurs. Based on this information,
this monitor attempts to detect transaction fault states and report them as part of SUPPORT level logging (
Currently, the monitor attempts to recognize the following fault states:
- TRANSACTIONMONITOR(1) - Leaked Resource: The transaction thread is not considered stuck, but no queries have been issued against the
tracked EntityManager in
loggingReportingLagThreshold. This could indicate the thread has moved on and the transaction was
not correctly finalized.
- TRANSACTIONMONITOR(2) - Long Running Transaction: The transaction thread is not considered stuck, but the transaction info has been alive
loggingThreshold. This is not necessarily a fault, but may warrant review. Long running or stuck
transactions can account for long resource lock times. Note, this case can later become a stuck thread if the
has not elapsed.
- TRANSACTIONMONITOR(3) - Exception During Finalization: The transaction is attempting to finalize normally, but has
experienced an exception during that finalization attempt. This could indicate a problem communicating with the backing
database and may result in orphaned resources in the data tier.
- TRANSACTIONMONITOR(4) - Stuck Thread: The transaction thread is considered stuck with a transaction info alive
loggingThreshold and no change in thread stack for
stuckThreshold. Long running or stuck transactions
can account for long resource lock times.
- TRANSACTIONMONITOR(5) - Alive At Shutdown: The transaction info is considered active at the time of container
shutdown. This is not necessarily a fault, but may warrant review. Items at shutdown may simply be waiting for
final closure. However, subsequent system kill calls (if applicable) could prematurely exit these connections and
they may be interesting for review.
This monitor is enabled or disabled per
If no enabled transaction manager is found, the monitor is fully disabled.
variable can be controlled via the 'log.transaction.lifecycle.logging.threshold.millis' property.
The default value is 600000.
variable can be controlled via the 'log.transaction.lifecycle.stuck.threshold.millis' property.
The default values is 300000.
variable can be controlled via the 'log.transaction.lifecycle.logging.polling.resolution.millis' property.
The default value is 30000.
variable can be controlled via the 'log.transaction.lifecycle.reporting.lag.threshold.millis' property.
The default value is 300000.
variable can be controlled via the 'log.transaction.lifecycle.info.count.max' property. The default value is 5000.
variable can be controlled via the 'log.transaction.lifecycle.use.compression' property.
The default value is true.
variable can be controlled via the 'log.transaction.lifecycle.abbreviate.statements' property.
The default value is true.
variable can be controlled via the 'log.transaction.lifecycle.abbreviate.statements.length' property.
The default value is 200.
variable can be controlled via the 'log.transaction.lifecycle.decompress.statement' property.
The default value is false.
variable can be controlled via the 'log.transaction.lifecycle.query.list.max.size' property.
The default value is 100.
This monitor is intended for temporary usage as part of transaction related debugging efforts. From both a heap utilization
and performance standpoint, this monitor is suitable for production with default settings. Performance impacts should be minor and will generally
be related to creation of the intial call stack, compression of that call stack and subsequent compression of sql statements.
Compression can be turned off via the 'log.transaction.lifecycle.use.compression' for a minor performance benefit at the cost
of additional heap usage. Heap usage can be capped via the 'log.transaction.lifecycle.info.count.max' property, but if the max
happens to be reached, new transactions will not be monitored. This is more a safety net feature than anything and it's not
anticipated that the default max count will be reached during normal usage. Set 'log.transaction.lifecycle.info.count.max' to
-1 to uncap growth.
To avoid overly large disk usage in logs (in case many log statements are emitted with many queries per), the system will truncate
statements to a default length of 200 characters and leave those statements compressed in the logs (if they were configured to be
compressed). See the
variable to change this behavior.
To view the decompressed version, you'll need to pass the compressed string from the log line to the
method to see the decompressed version. This can be easily done by writing a simple
main program that instantiates TransactionLifecycleMonitor and calls this method. To emit the uncompressed version of the
queries instead to the logs, change the
property value. Finally, by default, the system
will only remember and emit the last 100 queries in the transaction. This value can be tweaked via the
variable. Set this value to -1 to uncap the expansion of the query list.