How @Transactional Works in Spring

Direct Answer

@Transactional declares a transaction boundary. With the usual proxy-based setup, Spring intercepts a call through the bean proxy, asks the configured transaction manager to begin or join a transaction, runs the method, and then commits or rolls back. By default, RuntimeException and Error cause rollback; checked exceptions do not unless the rollback rules are changed.

Code Example

@Service
public class OrderService {
    @Transactional
    public Order createOrder(OrderRequest request) {
        var order = orderRepo.save(new Order(request.customerId()));
        inventoryRepo.reserveIfAvailable(request.items());
        return order;
    }

    @Transactional(readOnly = true) // intent hint; effect depends on manager/provider
    public Optional<Order> findOrder(Long orderId) {
        return orderRepo.findById(orderId);
    }
}

This forms one transaction only when both repositories use the participating transactional resource. A default rollback exception must escape for the first method to roll back automatically.

Common Mistakes & Pitfalls

• Misreading self-invocation: A same-object call bypasses the proxy, so the inner annotation is ignored. An outer transaction may still be active; the mistake is claiming that no transaction can exist at all.
• Using a private method: A proxy cannot intercept a private method. Current class-based proxies can support protected or package-visible methods, while interface-based proxies require calls through the interface's public methods.
• Assuming every exception rolls back: By default, RuntimeException and Error cause rollback. Configure rollbackFor when a checked exception should roll back.