Spring’s Most Misunderstood Class Is Quietly Running Your @Transactional

You’ve been there. You annotate a method with @Transactional, call it from another method in the same class, and nothing happens. No transaction starts. No rollback fires. No error. Just silence — the kind that makes you question every decision that led you to this career.

You spend three hours on Stack Overflow. Every answer says “it’s a proxy thing.” Nobody explains what that actually means.

Every Spring developer has stared at a broken @Transactional method and wondered why the universe abandoned them. The answer isn’t in your code — it’s in a class you’ve probably never opened: AbstractSingletonProxyFactoryBean.

Let’s talk about this class. Not because it’s glamorous. Because it’s the hidden machinery behind every @Transactional, @Secured, and @Async annotation you’ve ever written. And because misunderstanding it is the number one reason your cross-cutting concerns silently fail in production.

Here’s what most developers get wrong: they hear “AOP proxy” and immediately think “Python decorator.” Someone even asked this exact question in the comments of Spring’s own documentation. And it’s a reasonable comparison — both wrap existing behavior with additional logic. But it’s also fundamentally, dangerously wrong.

A Python decorator wraps your function at definition time. Spring’s proxy wraps your entire bean at lifecycle time — and that distinction is why your self-invocation doesn’t trigger advice.

When you write a Python decorator, the wrapping happens the moment the interpreter sees the @syntax. The function object is replaced. Every call — internal or external — hits the wrapper. Simple. Predictable. Transparent.

Spring doesn’t work that way. Spring doesn’t replace your class. Spring builds a completely separate object — a proxy — that sits in front of your bean inside the IoC container. When external code calls your bean, it actually calls the proxy, which dispatches to advice (transaction begin, security check, async execution) and then forwards to your real method. Clean. Powerful. And completely invisible when it breaks.

But when your bean calls its own internal method? It’s not going through the proxy. It’s calling this directly — the raw, unwrapped object. No advice. No transaction. No safety net. The proxy doesn’t exist from the inside.

This is the tension at the heart of AbstractSingletonProxyFactoryBean, and it’s right there in the name. “Singleton” means one instance — static, stable, shared. “Proxy factory” means dynamic dispatch — advice chains, invocation handlers, runtime decisions. The factory itself is a singleton in the container. But the proxy it produces must dynamically route every call through an advice chain.

The singleton isn’t the proxy. The singleton is the factory that produces it. One instance, infinite dispatch paths. Spring blends static scoping with dynamic behavior — and that’s either brilliant architecture or a debugging nightmare, depending on whether you understand it.

So why does Spring do it this way instead of just replacing the class like Python does? Because Spring isn’t decorating functions. Spring is managing the entire lifecycle of objects inside a container. The proxy needs to be created after dependency injection completes. It needs to participate in the bean lifecycle — initialization, destruction, scoping. It needs to be a first-class citizen of the IoC container, not a syntactic wrapper bolted on at parse time.

This is why you can’t just “understand AOP” by reading about pointcuts and advice. The real complexity lives in the integration layer — how the proxy is created, when it’s created, and how it dispatches. AbstractSingletonProxyFactoryBean is that integration layer.

When you finally understand this class, a cascade of mysteries suddenly makes sense. Why @Transactional only works on public methods (the proxy can’t intercept non-public calls). Why self-invocation breaks everything (you bypass the proxy). Why bean post-processing order matters (the proxy must be built after all advice is configured). Why circular dependencies with proxied beans are especially painful (the proxy isn’t ready when injection happens).

Self-invocation doesn’t fail because Spring is broken. It fails because you’re calling the object, not the proxy. You walked around the security checkpoint and wondered why nobody stopped you.

Here’s what I want you to take away: stop treating AOP as magic annotations that just work. They work because a factory — a singleton factory — constructs a proxy that intercepts your calls and dynamically dispatches them through an advice chain. That proxy is a real object in your container with a real lifecycle, and it has real limitations.

If you’re building custom infrastructure — your own annotations, your own cross-cutting concerns, your own transaction-like wrappers — you will eventually need to create proxy beans yourself. And when you do, AbstractSingletonProxyFactoryBean is your blueprint. It handles the boring, critical work: singleton scoping, target configuration, advice chain assembly, proxy interface exposure.

The developers who master Spring aren’t the ones who memorize annotations. They’re the ones who understand the machinery underneath. And this class is the machinery.

So the next time your @Transactional silently fails, don’t blame the annotation. Don’t blame Spring. Look at the proxy. Ask yourself: did this call actually go through the proxy, or did I just call the raw bean?

The proxy is always honest. It’s your assumptions about where it lives that lie to you.