Spring HTTP request lifecycle timeline
Follow one request through filters, the DispatcherServlet, interceptors, validation, the controller, the transaction proxy and the exception advice. Pick a scenario and see what runs, what is skipped and when the transaction commits.
transaction opencommittedrolled backfaded = not reached
Where each Spring feature sits in a request
A request to a Spring Boot application passes through several layers before your code runs, and the order matters when something fails. The servlet filter chain comes first. This is where Spring Security authenticates the caller, where CORS and CSRF are checked and where access logging usually lives. A filter can answer the request itself, which is why a 401 never touches your controller advice.
Next the DispatcherServlet maps the URL to a handler and runs the interceptors. preHandle can veto the request. Then arguments are resolved: Jackson reads the JSON body and bean validation runs. If validation fails, the controller method is never entered and no transaction was ever opened.
Where the transaction lives
The controller normally runs outside a transaction. The transaction begins when the call crosses the proxy around a @Transactional service. It ends when that call returns, committing on success or rolling back on an unchecked exception. Two traps are worth remembering and both are scenarios above: a checked exception still commits, and a call to a transactional method from inside the same class never goes through the proxy, so there is no transaction at all.
Exceptions and cleanup
When something throws, Spring MVC asks its exception resolvers, and your @RestControllerAdvice turns the exception into a status and body. postHandle is skipped, but afterCompletion always runs for interceptors that let the request in, so that is the place to clear a ThreadLocal or MDC value. Finally the response travels back out through the filters.
Learn the concepts
Filters and interceptors ·Exception handling ·@Transactional ·AOP proxies ·Security filter chain ·Propagation and isolation
Frequently asked questions
What is the difference between a servlet filter and a Spring interceptor?
A filter belongs to the servlet container and wraps the whole request, including requests that never reach Spring MVC (Spring Security is a filter chain). A HandlerInterceptor belongs to Spring MVC, runs only for requests that matched a handler, and can see the handler method. Filters see raw requests; interceptors see the matched controller.
Does @ControllerAdvice catch exceptions thrown in filters?
No. @ControllerAdvice is part of DispatcherServlet, so it handles exceptions from interceptors, argument resolution, controllers and services. An exception from a servlet filter, including Spring Security, never reaches it; use an AuthenticationEntryPoint, AccessDeniedHandler or an error page instead.
When does a Spring transaction roll back?
By default, on an unchecked exception (RuntimeException or Error) leaving the @Transactional method. A checked exception commits the transaction unless you add rollbackFor. The transaction only exists if the call went through the Spring proxy.
Why is @Transactional ignored when I call a method on this?
Spring implements @Transactional with a proxy around the bean. A call from another bean goes through the proxy; a call from inside the same class goes straight to the method and skips the interceptor, so no transaction is started. Move the method to another bean or call it through the injected proxy.
Does afterCompletion run when the controller throws?
Yes. afterCompletion runs for every interceptor whose preHandle returned true, even after an exception, which makes it the right place to clean up. postHandle does not run when an exception occurs.