Proxy Pattern in Spring?

Question

Accepted Answer

**Proxy Pattern** — an object that **controls access** to another object (the real one). Spring uses proxies everywhere: @Transactional, @Async, @Cacheable, @PreAuthorize.

**Simple analogy:** A proxy is like a director's secretary. You call the secretary (proxy), not the director (real object). The secretary checks if you can be let in (security), opens the door (transaction), lets you talk to the director, then closes the door (commit/rollback). You never interact with the director directly — the secretary handles all the overhead.

**Why it matters:** Spring's "magic" — transactions, security, caching — is implemented through proxies. When you add `@Transactional`, Spring does not modify your class. It wraps it in a proxy that intercepts every method call, starts a transaction before the call, and commits/rolls back after. Understanding proxies explains why some Spring features "silently fail" and how to fix them.

**How Spring creates proxies:**
```java
@Service
public class UserService {
    @Transactional  // Spring creates a proxy around this class
    public void updateUser(Long id, User user) {
        // Your code
        userRepository.save(user);
    }
}

// What Spring does (simplified):
// UserService$$EnhancerBySpringCGLIB$$abc123 — this is the proxy
// On invocation:
// 1. Open transaction
// 2. Call the original method
// 3. Commit or rollback
```

**Two types of proxies:**
1. **JDK Dynamic Proxy** — via interfaces (`java.lang.reflect.Proxy`). The proxy implements the same interface.
2. **CGLIB Proxy** — via inheritance (creates a subclass). Default in Spring Boot since Boot 2. Works even without interfaces.

```java
// JDK proxy example
public interface UserService {
    void updateUser(Long id, User user);
}

// CGLIB proxy example — no interface needed
@Service
public class UserServiceImpl {
    @Transactional
    public void updateUser(Long id, User user) { ... }
}
```

**Self-invocation problem (the #1 proxy pitfall):**
```java
@Service
public class UserService {
    public void methodA() {
        methodB();  // Called via this, NOT through the proxy!
    }

@Transactional
    public void methodB() { ... }
    // @Transactional will NOT work for methodA() → methodB()
}
```

**Why it fails:** `methodA()` calls `this.methodB()`, which goes directly to the real object, bypassing the proxy. The transaction interceptor never sees the call.

**Solutions:**
```java
// Solution 1: Self-inject
@Service
public class UserService {
    @Autowired
    private UserService self;  // This is actually the proxy!

public void methodA() {
        self.methodB();  // Through the proxy!
    }
}

// Solution 2: Extract transactional method to a separate bean
@Service
public class UserService {
    @Autowired
    private UserTransactionHelper helper;

public void methodA() {
        helper.methodB();  // Different bean → goes through proxy
    }
}
```

**Proxy in Spring Security:**
Every bean in Spring is wrapped in a proxy by default for @PreAuthorize, @Secured, etc. This is why you can secure methods declaratively — the proxy checks permissions before forwarding to the real method.

**Common pitfalls:**
- **`final` classes cannot be proxied** — CGLIB works by subclassing. `final` prevents subclassing, so `@Transactional` on a `final` class is silently ignored.
- **Package-private methods** — CGLIB proxies call via subclass overriding. Package-private methods in a different package cannot be intercepted.
- **Proxy overhead** — each method call goes through an interceptor chain. For extremely hot paths (millions of calls/second), this adds measurable overhead.

Java: Proxy Pattern in Spring?