Transaction Control

The Transaction Control page finds @Transactional methods that keep a database connection busy longer than they should: blocking network calls, N+1 queries, and in-memory pagination inside the transaction. For each problem, it shows where it happens, so you can find the place in the code.

ScreenshotsScreenshots show the latest minor release of Axelix.

transaction control main page

Transaction Control as presented in Axelix UI

While a transaction is open, it holds a database connection from the pool. When the transaction does extra work, such as calling another service, running one query per record, or loading a whole table to show one page, connections run out and the application slows down under load. The code rarely makes this obvious. Transaction Control shows which @Transactional methods do this and where exactly.

The page is read-only and available to every authenticated user: VIEWER, EDITOR, ADMIN, and SUPER_ADMIN can all open it. See Roles and authorities for the full role/authority matrix.

What the page shows

The page lists every @Transactional method the instance has run, with its average, fastest, and slowest execution time and the problems found in it. A summary on top shows how many transactions have problems and how many are clean, and you can narrow the list to one type of problem.

Expand a transaction to see:

Where each problem happened: the called URL, the entity and association, or the entity paginated in memory.
The propagation and isolation level of the transaction.
The access: read-only or read-write.

When no transaction has problems, the page says so instead of showing the list.

Detected problems

Blocking network call: The transaction makes an HTTP call and keeps its connection while waiting for the answer. Axelix shows the request method and URL. Axelix currently detects calls made through RestTemplate.
N+1 queries: A lazy association is loaded with a separate query for each record. Axelix shows the entity and the association, and counts it only when the association was loaded more than once.
In-memory pagination: Pageable is combined with JOIN FETCH, so Hibernate loads the whole result set and cuts the page in memory. Axelix shows the entity or table.

How it works

The Axelix Spring Boot Starter watches every @Transactional method call inside the application and measures how long it takes. While the transaction is open, it records HTTP calls made through RestTemplate and lazy loads of Hibernate associations, and catches the Hibernate warning about in-memory pagination in the application logs (Logback or Log4j2). No agent or APM tool is required.

MCP Tools

AI agents can get the N+1 queries and in-memory pagination found in an application's transactions through MCP, for the whole application or for one class or method. Blocking network calls are not included. See the MCP Tools catalog.

Properties

Transaction monitoring is enabled by default. To turn it off entirely, set axelix.sbs.transaction.monitoring.enabled=false. See Transaction monitoring for details.

Expose the metadata endpoint

The page is not backed by a dedicated actuator endpoint. The Axelix Spring Boot Starter aggregates the transaction insights on the JVM and ships them to Master as part of the instance's registration metadata: the same payload exposed through the axelix-metadata endpoint that Master already probes. As long as axelix-metadata is exposed (see Exposing the endpoints on Axelix below 1.2.0), this page works with no extra endpoint to enable.