An annotation is not evidence of a transaction
Transactional code should make an intended database unit succeed or fail together. Seeing @Transactional on a method does not prove that every invocation enters a transaction. The runtime call path, transaction configuration, selected manager and exception behavior determine what actually happens.
In Spring's default proxy mode, calls arriving through the proxy are intercepted. A method calling another method on the same target object does not cross that proxy boundary. This guide investigates that specific self-invocation problem. It does not solve remote API consistency or claim that a local database transaction can undo an email or payment already sent.
Setup: draw the real invocation path
Start with the controller, scheduled job or message handler that initiates the work. Follow the actual object references to the transactional operation. Confirm that the relevant service is managed by Spring and identify the transaction manager and datasource. Record whether the application uses the default proxy arrangement or deliberately configured weaving.
Create a test operation that writes two synthetic records and fails between them using a controlled exception. Specify the expected database state. Review the installed framework version's rollback rules for that exception; do not assume every exception type behaves identically. Keep this experiment away from live orders and customer balances.
Illustrative incident: the helper method looks protected
An illustrative import service calls its own annotated helper to create a batch. A failure leaves part of the batch stored. The team considers stronger isolation, but call tracing shows the helper was reached through self-invocation in proxy mode. Isolation cannot repair a boundary that was never entered as intended. This is a teaching scenario, not a client result.
Collect the entry path, bean configuration, transaction diagnostics and database state from the failing fixture. If a test framework wraps the entire test in its own transaction, it can conceal how the application behaves without that wrapper. Design the acceptance test to observe the production entry boundary.
Troubleshooting: distinguish boundary from rollback policy
| Observation | Evidence | Investigation |
|---|---|---|
| Internal helper does not start the intended transaction | Caller object and proxy path | Is this self-invocation? |
| Transaction exists but data remains | Exception type and rollback configuration | Did the exception trigger the expected rollback rule? |
| Only one datasource rolls back | Manager selection and datasource ownership | Are multiple independent resources involved? |
| Test passes, deployed path fails | Test transaction wrapper and entry point | Is the test creating a different boundary? |
Do not respond by changing isolation, adding retries or catching the exception and returning success. Those changes can make the underlying lifecycle harder to observe and may repeat partially completed work.
Corrective action: choose an explicit service boundary
Where appropriate, move the database unit into a separate managed service and invoke it through that service's public boundary. Another deliberate option may be programmatic transaction management. Choose according to the architecture and team's operating knowledge, then test the resulting path. Do not introduce self-injection tricks or weaving as an unexplained one-line patch.
Keep the unit small enough to avoid unnecessary lock duration. Review exception handling so errors that require rollback are not accidentally consumed before the transactional boundary observes them. If multiple datasources or external side effects are involved, document those consistency boundaries separately. A repair for self-invocation does not automatically make the whole workflow atomic.
Verification, SLO and SOP
Run the controlled failure through the real application entry path and inspect committed database state after the operation ends. Repeat the success case, expected business rejection and the relevant checked or unchecked exception cases. Confirm that error reporting does not tell the caller a rollback occurred when partial business work remains elsewhere.
An internal data-integrity objective can track accepted operations meeting their atomicity contract. Monitor transaction failures, lock waits and reconciliation separately; low HTTP error rate does not establish data correctness. A contractual SLA needs explicit scope. The SOP should identify the transaction owner, test fixture, manager selection, rollback policy and escalation route for partial state.
Explore software development and database administration for coordinated application and persistence review.
Technical reference
Spring declarative transaction annotations, reviewed 19 October 2026. Confirm behavior for the configured proxy or weaving mode and installed release.