Transactions in JVM
Transactions recorded in JVM can behave in two ways depending on whether or not the transaction originated in a browser with the Plumbr Browser Agent. Every inbound request arriving to a JVM monitored by the Plumbr Java Agent performs a check to detect whether or not the Browser Agent was present.
If the Browser Agent was present, the JVM processing the request in the Server side is joined with the existing transaction. All the processing done by the Server-side JVM(s) is then linked to the ongoing transaction as spans. In this case the outcome is the end-to-end transparency of the transaction throughout the infrastructure.
If no transaction is started in the end user’s browser, the transaction is started the moment it arrives to the JVM. This happens when:
- the browser triggering the request does not have the Plumbr Browser Agent attached
- the request is not made by a human using a browser, but by another system using the web services published by the JVM
- the inbound operation arriving to the JVM is not an HTTP request. Besides supporting transactions for web applications, Plumbr Java Agent also captures transactions from remote calls to EJB modules and Swing event listeners in Swing-based desktop applications.
In such a case the transaction includes the duration and processing carried out in the Server side.
The benefits of tracking the transactions in backend JVMs in addition to the Browser Agent include the following:
- the user’s identity is exposed. By doing this, Plumbr will not only keep track of the number of users on your site but also identifies each user
- failed and slow transactions expose the root cause in the source code. This allows you to rank performance issues by their impact on end users and proceed with a fix, knowing both the impact and the location of the root cause in the source code