Asked  7 Months ago    Answers:  4   Viewed   32 times

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!


Why only external method calls will be under Transaction and not the self-invocation methods?



This is a big topic. The Spring reference doc devotes multiple chapters to it. I recommend reading the ones on Aspect-Oriented Programming and Transactions, 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 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.

Tuesday, June 1, 2021
answered 7 Months ago

The reason that moving the context:component-scan tags to the application context xml fixed the transactional behavior is: <tx:annotation-driven /> is a post-processor that wraps @Transactional annotated bean methods with an AOP method interceptor which handles transactional behavior. Spring post-processors, only operate on the specific application context they are defined in.

In your case, you have defined the <tx:annotation-driven /> post-processor in the application context, while the beans annotated with @Transactional are in the servlet application context. Thus, the <tx:annotation-driven /> post-processor only operated on the application context beans, not the servlet context beans. When the context:component-scan tags were moved to the application context, then the <tx:annotation-driven /> post-processor wrapped their transactional methods appropriately.

Hope that makes some sense.


What is the difference between the Application Context and a Servlet Context?

What is a Spring post-processor and how does it work?

What is AOP in Spring?

Thursday, June 3, 2021
answered 7 Months ago

Found the answer here: Table 2 indicates that the advice for the Transactional annotation has an order of Ordered.LOWEST_PRECEDENCE, which means that it is safe to combine Retryable with Transactional as long as you aren't overriding the order of the advice for either of those annotations. In other words, you can safely use this form:

public void performDatabaseActions() {
    //Database updates here that may cause an optimistic locking failure 
    //when the transaction closes
Thursday, August 12, 2021
Mark Comix
answered 4 Months ago

Generally in Hibernate , in the same transaction , while flushing(committing) it always follows a particular order.

Inserts are first executed and then deletes are executed while flushing.

So ideally in your case , since you are deleting before insert just call enitityManager.flush() explicitly after delete .

Alternatively also have a look at EntityManager.setFlushMode() method where you can set to flush mode type to either commit or auto

Wednesday, December 1, 2021
answered 1 Week ago
Only authorized users can answer the question. Please sign in first, or register a free account.
Not the answer you're looking for? Browse other questions tagged :