I want to know what actually happens when you annotate a method with `@Transactional`?
Of course, I know that Spring will wrap that method in a Transaction.

But, I have the following doubts:

1. I heard that Spring creates a **proxy class**? Can someone explain this in more **depth**. **What actually resides in that proxy class? What happens to the actual class? And how can I see Spring's created proxied class**
2. I also read in Spring docs that:

> 
> *Note: Since this mechanism is based on proxies, **only 'external' method calls coming in through the proxy will be intercepted**. This means that 'self-invocation', i.e. a method within the target object calling some other method of the target object, won't lead to an actual transaction at runtime even if the invoked method is marked with `@Transactional`!*
> 
> 
> 

Source: <http://static.springsource.org/spring/docs/2.0.x/reference/transaction.html>

**Why only external method calls will be under Transaction and not the self-invocation methods?**
['https://Stackoverflow.com/questions/1099025', 'https://Stackoverflow.com', 'https://Stackoverflow.com/users/133830/']
This is a big topic. The Spring reference doc devotes multiple chapters to it. I recommend reading the ones on [Aspect-Oriented Programming](https://docs.spring.io/spring-framework/docs/current/reference/html/core.html#aop-api) and [Transactions](https://docs.spring.io/spring-framework/docs/current/reference/html/data-access.html#transaction), as Spring's declarative transaction support uses AOP at its foundation.

But at a very high level, Spring creates proxies for classes that declare `@Transactional` on the class itself or on members. The proxy is mostly invisible at runtime. It provides a way for Spring to inject behaviors before, after, or around method calls into the object being proxied. Transaction management is just one example of the behaviors that can be hooked in. Security checks are another. And you can provide your own, too, for things like logging. So when you annotate a method with `@Transactional`, Spring dynamically creates a proxy that implements the same interface(s) as the class you're annotating. And when clients make calls into your object, the calls are intercepted and the behaviors injected via the proxy mechanism.

Transactions in EJB work similarly, by the way.

As you observed, through, the proxy mechanism only works when calls come in from some external object. When you make an internal call within the object, you're really making a call through the `this` reference, which bypasses the proxy. There are ways of working around that problem, however. I explain one approach in [this forum post](http://forum.springsource.org/showthread.php?t=11656) in which I use a `BeanFactoryPostProcessor` to inject an instance of the proxy into "self-referencing" classes at runtime. I save this reference to a member variable called `me`. Then if I need to make internal calls that require a change in the transaction status of the thread, I direct the call through the proxy (e.g. `me.someMethod()`.) The forum post explains in more detail.

Note that the `BeanFactoryPostProcessor` code would be a little different now, as it was written back in the Spring 1.x timeframe. But hopefully it gives you an idea. I have an updated version that I could probably make available.
As a visual person, I like to weigh in with a sequence diagram of the proxy pattern. If you don't know how to read the arrows, I read the first one like this: `Client` executes `Proxy.method()`.

1. The client calls a method on the target from his perspective, and is silently intercepted by the proxy
2. If a before aspect is defined, the proxy will execute it
3. Then, the actual method (target) is executed
4. After-returning and after-throwing are optional aspects that are
executed after the method returns and/or if the method throws an
exception
5. After that, the proxy executes the after aspect (if defined)
6. Finally the proxy returns to the calling client

![Proxy Pattern Sequence Diagram](https://i.imgur.com/Ye9pEVI.jpg)
(I was allowed to post the photo on condition that I mentioned its origins. Author: Noel Vaes, website: <https://www.noelvaes.eu>)