Develop Reference

Transactional method called by method in same class called from another class

I have a transactional method that is called called multiple time (in a loop) by a method in the same class.
This method in the same class is called by a method in a different class.
From my investigation, when we call a transaction method within the same class, this has no effect. The same transaction is used.
But in my case, will a new transaction be used?
Structure:
A.class - Method A
|-> B.class - Method A
|-> call mutiple times - B.class - #Transactional Method B
Can you advise?
My expectations is that a new transaction on Method B is created each time I loop through it.
Do I need to pass the Method B to a different class? Or it will start a new transaction every time?

So BY DEFAULT two things are potentially working against you.
Spring's default txn interceptors, which is how AOP transactions work, will not pick up calls within the same instance. This can be changed by switching to AspectJ weaving. This article has a good explanation https://www.baeldung.com/spring-aop-vs-aspectj IIRC the default in spring is jdk proxying.
Spring's default transactional annotation will propagate existing txns. So if there's not a pre-existing txn AND you overcome the above you should get what you want. If there's a pre-existing txn, it will by default be used, but this behaviour can be changed by modifying the propagate parameter on your #Transactional annotation. This article has a good explanation: https://www.baeldung.com/spring-transactional-propagation-isolation

Why can't we use #Cacheable with static method in spring with ehcache?

I am new to Spring and read that we can't use #Cacheable with static method but can't found why we can't use so any one can explain so that beginner can understood easily?
Can we use static method for retrieving database table?
I have made static method of all method of service layer of DAO so Is this thread-safe?

Elaborating on my comment:
"Static methods cannot be cached. The way aspects work in Spring is by adding a wrapper class (a proxy) to the annotated class. There is no way in Java to add a wrapper to a static method."
Since Spring needs an object to wrap around in order to intercept calls to that object and perform various operations before delegating the modified input to the original object (thus spring aspects are possible).
Since anything that is static cannot be instantiated as an object, Spring has no way to wrap around it and intercept its calls (at least with the current implementation of Spring)

It is a limitation of the mechanism used to provide caching.
When you mark some method as #Cacheable, Spring creates a proxy to your bean that intercepts method invocations and provides the caching, and will inject that instead of the original bean. So if you have some code like:
#Inject
private MyBean myBean;
...
myBean.myMethod("foo");
where MyBean has declared myMethod() as #Cacheable, then myBean will not point to what you put in the application context, but to a proxy that will do the caching and invoke the original MyBean.myMethod() only when cache lookup does not return anything.
Proxys cannot intercept static methods, so the proxy cannot cache static methods. That is why #Cacheable will not work on static methods.

Diagnosing transactional exceptions in Spring Data

Working with Spring Data Neo4j (using simple mapping mode), I occasionally come across NotInTransactionException's being thrown inside methods that are annotated with #Transactional, and have found myself pulling out more hairs than I can afford to lose trying to diagnose these exceptions. For example, the following method:
#Service
public class FooService {
#Autowired Neo4jTemplate template;
//GraphPersisted is an interface containing a single method: Long getId()
//ModelNode is an empty interface implemented by my #NodeEntity classes
#Transactional
public <T extends ModelNode> T getNode(GraphPersisted g, Class<T> clazz){
return template.repositoryFor(clazz).findOne(g.getId()); //NotInTransactionException!!
}
}
is throwing the following:
Caused by: org.springframework.dao.InvalidDataAccessApiUsageException: nested exception is org.neo4j.graphdb.NotInTransactionException
at org.springframework.data.neo4j.support.Neo4jExceptionTranslator.translateExceptionIfPossible(Neo4jExceptionTranslator.java:51)
at org.springframework.data.neo4j.support.Neo4jTemplate.translateExceptionIfPossible(Neo4jTemplate.java:447)
at org.springframework.data.neo4j.support.Neo4jTemplate.getNode(Neo4jTemplate.java:481)
at org.springframework.data.neo4j.repository.NodeGraphRepositoryImpl.getById(NodeGraphRepositoryImpl.java:33)
at org.springframework.data.neo4j.repository.NodeGraphRepositoryImpl.getById(NodeGraphRepositoryImpl.java:24)
at org.springframework.data.neo4j.repository.AbstractGraphRepository.findOne(AbstractGraphRepository.java:127)
at org.springframework.data.neo4j.repository.AbstractGraphRepository.findOne(AbstractGraphRepository.java:51)
at net.mypkg.myapp.core.FooService.getNode(FooService.java:28)
at net.mypkg.myapp.citizenry.BarService.getCitNode(BarService.java:136)
at net.mypkg.myapp.citizenry.BarService.loadCitizens(BarService.java:81)
at net.mypkg.myapp.citizenry.BarService$$FastClassBySpringCGLIB$$792b7a4e.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:640)
at net.mypkg.myapp.citizenry.BarService$$EnhancerBySpringCGLIB$$59949515.loadCitizens(<generated>)
at net.mypkg.myapp.creator.builders.VotingActivityBuilder.makeVotesFor(VotingActivityBuilder.java:46)
at net.mypkg.myapp.creator.builders.VotingActivityBuilder.build(VotingActivityBuilder.java:35)
at net.mypkg.myapp.creator.builders.VotingActivityBuilder$$FastClassBySpringCGLIB$$6871225a.invoke(<generated>)
at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:640)
at net.mypkg.myapp.creator.builders.VotingActivityBuilder$$EnhancerBySpringCGLIB$$7f5827a1.build(<generated>)
at net.mypkg.myapp.creator.Creator.create(Creator.java:33)
at net.mypkg.myapp.creator.CreatorDriver.run(CreatorDriver.java:52)
at org.springframework.boot.SpringApplication.runCommandLineRunners(SpringApplication.java:634)
... 5 more
My most immediate question is: Why is this exception being thrown? Why is my #Transactional annotation not doing what I expect it to do (namely wrapping my call to template.findOne(Long id) in a transaction)?
My larger question is: How do you know? What clues are given in the stack trace that might indicate from whence the unexpected behavior is arising? I'm relatively new to Spring and Spring Data, and I'm sure these issues aren't inherently difficult to diagnose, I'm just struggling to do so because I don't know how to interpret the stack trace: What should I be looking for in the trace to diagnose these problems when they arise?
(Please let me know what further code/config is necessary to answer this question and I'll post it - I've purposely included as little as possible, in hopes that what you need to see to diagnose this specific issue will help me understand what I need to be looking at to diagnose similar exceptions in the future. I will say, though, that #Transactional annotations are working as expected for a large number of other methods in the same application context)

To wrap some thoughts up in an answer: Spring (any recent version) establishes transactions by instantiating proxies for objects containing a method annotated with "#Transactional". These proxies (wrapping the original functionality with enter- / exit-code handling a transaction) are generated in one of two ways:
1) via CGLIB by dynamically generating Java byte code for the subclass of the proxy target overriding the annotated method, using an instance of this subclass plus using an instance of the original class
2) via Java Dynamic Proxies mimicing the targeted class by dynamically generating an object implementing all the interfaces of the proxy target plus using an instance of the original class
Spring tries to go with 2) unless explicitly otherwise told. As 2) doesn't work if the target class doesn't implement any interfaces option 1) has to be chosen. Falling back to option 1) may break, too. Think about final methods (as Maarten mentioned) or method with a stricter scope than public.
These general things are all documented in the Spring reference (look for "cglib", "proxy", "transaction", ...).
Coming back to your example (hoping its not accidentally oversimplified):
a) the class FooService containing the annoted method getNode does not implement any interface (by the way this is really a bad practice; you ought to program against an interface, e.g. easily allowing you to exchange the implementation), Spring has to go the "CGLIB way". Using CGLIB should work, as nothing is final, the annotated method is public, calling the base class constructor twice doesn't do any harm, ...
b) calling from the stacktrace we can tell that the classes BarService and VotingActivityBuilder are proxied using CGLIB, so generally this does work.
c) if the mentioned BarService and VotingActivityBuilder are proxied because of an #Transactional annotation, you've successfully setup an transaction manager and enabled annotation driven transactions (via <tx:annotation-driven/> or #EnableTransactionManagement). Though I fear these two objects are proxied for other reasons (tell us! :-)). In the latter case instantiate a transaction manager and enable annotation driven transactions (cf. Maarten's answer).
d) lets exclude the case of multiple tx managers (you only have one, don't you?)
e) looking at the stacktrace we can exclude the case of internally calling setNode (i.e. calling it from another, not tx aware method of FooService). Doing so would bypass the proxied version of the annotated method.
f) last thing I can imagine for now (but can't tell from the stacktrace or your provided code for sure), is your code having more than one ApplicationContext (e.g. Web-Apps usually have a "root context" as well as a "dispatcher context" having a parent-child relation). If you instantiate FooService as part of a parent context and put #EnableTransactionManagement at your child context, then no tx logic will be generated.
I'd go for c) or f).
PS: A stacktrace of a proxied FooService throwing an exception in a tx annotated method setNode looks on my machine like
java.lang.IllegalArgumentException: This is for testing purposes.
at eu.example.service.FooService.getNode(FooService.java:94)
at eu.example.service.FooService$$FastClassByCGLIB$$837ba2c0.invoke(<generated>)
at o.s.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
at o.s.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:698)
at o.s.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at o.s.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:96)
at o.s.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:260)
at o.s.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:94)
at o.s.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at o.s.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:631)
at eu.example.service.FooService$$EnhancerByCGLIB$$e1fb8939.getNode(<generated>)

Judging from the stacktrace, an instance of BarService is making a call to a non proxied instance of FooService. If the latter where proxies, you would see CGLibEnhance-ed classes in the stacktrace and -IIRC- in your case also the TransactionInterceptor that is responsible for starting the transaction.
Now as to why the instance is not proxied, that is hard to say. Is #EnableTransactionManagement missing? Is the instance not managed by Spring? Can the class not be proxied because it is final?

Specifying the order of proxy creation in Spring

I have a Spring Application where I have the following skeleton class
class ServiceCaller
{
public Result callService()
{
//call a remote service
}
}
Since calling a remote service is an expensive operation, I added caching in my application. I used EhCache Spring annotations #Cacheable and applied it to the callService() method. Everything was working fine and my Result objects were getting correctly cached.
Later I wanted to add a logger across all my ServiceCallers such that my logger would record every actual call to a remote service. I did not want to manually add logger.info() to every such callService method so I decided to use a Spring AOP to implement this.
I defined a pointcut after-returning to all the methods that I wanted to log. It was working; however I noticed that my logger point cut was invoked even when I had a cache hit and my actual callService method was not called. This, I observed, was happening because the order of my proxy to the ServiceCaller bean was as follows: AOPPointCutProxy(EhCacheCachingProxy(ServiceCallerBean)). I want my logger pointcut to be invoked only when my actual callService method is called and not when it is returning with a cached value from the EhCache proxy. Which means that I actually want my proxy creation hierarchy to be in the form of EhCacheCachingProxy(AOPPointCutProxy(ServiceCallerBean)). Note that my bean definitions, pointcut definitions, cache configs may all be in different randomly named xml files.
So how do I enforce Spring to create the proxies in the order I want?

That is what the Ordered interface is used for. You need to implement that on your beans.
You can create a proxy that gets all of the proxies injected that should surround you call. Only that composite proxy surrounds the actual bean. Upon invocation it calls the injected proxies in their specified order.

Spring - #Transactional - What happens in background?

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:
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
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?

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.

When Spring loads your bean definitions, and has been configured to look for #Transactional annotations, it will create these proxy objects around your actual bean. These proxy objects are instances of classes that are auto-generated at runtime. The default behaviour of these proxy objects when a method is invoked is just to invoke the same method on the "target" bean (i.e. your bean).
However, the proxies can also be supplied with interceptors, and when present these interceptors will be invoked by the proxy before it invokes your target bean's method. For target beans annotated with #Transactional, Spring will create a TransactionInterceptor, and pass it to the generated proxy object. So when you call the method from client code, you're calling the method on the proxy object, which first invokes the TransactionInterceptor (which begins a transaction), which in turn invokes the method on your target bean. When the invocation finishes, the TransactionInterceptor commits/rolls back the transaction. It's transparent to the client code.
As for the "external method" thing, if your bean invokes one of its own methods, then it will not be doing so via the proxy. Remember, Spring wraps your bean in the proxy, your bean has no knowledge of it. Only calls from "outside" your bean go through the proxy.
Does that help?

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().
The client calls a method on the target from his perspective, and is silently intercepted by the proxy
If a before aspect is defined, the proxy will execute it
Then, the actual method (target) is executed
After-returning and after-throwing are optional aspects that are
executed after the method returns and/or if the method throws an
exception
After that, the proxy executes the after aspect (if defined)
Finally the proxy returns to the calling client
(I was allowed to post the photo on condition that I mentioned its origins. Author: Noel Vaes, website: https://www.noelvaes.eu)

The simplest answer is:
On whichever method you declare #Transactional the boundary of transaction starts and boundary ends when method completes.
If you are using JPA call then all commits are with in this transaction boundary.
Lets say you are saving entity1, entity2 and entity3. Now while saving entity3 an exception occur, then as enitiy1 and entity2 comes in same transaction so entity1 and entity2 will be rollback with entity3.
Transaction :
entity1.save
entity2.save
entity3.save
Any exception will result in rollback of all JPA transactions with DB.Internally JPA transaction are used by Spring.

All existing answers are correct, but I feel cannot give this complex topic justice.
For a comprehensive, practical explanation you might want to have a look at this Spring #Transactional In-Depth guide, which tries its best to cover transaction management in ~4000 simple words, with a lot of code examples.

It may be late but I came across something which explains your concern related to proxy (only 'external' method calls coming in through the proxy will be intercepted) nicely.
For example, you have a class that looks like this
#Component("mySubordinate")
public class CoreBusinessSubordinate {
public void doSomethingBig() {
System.out.println("I did something small");
}
public void doSomethingSmall(int x){
System.out.println("I also do something small but with an int");
}
}
and you have an aspect, that looks like this:
#Component
#Aspect
public class CrossCuttingConcern {
#Before("execution(* com.intertech.CoreBusinessSubordinate.*(..))")
public void doCrossCutStuff(){
System.out.println("Doing the cross cutting concern now");
}
}
When you execute it like this:
#Service
public class CoreBusinessKickOff {
#Autowired
CoreBusinessSubordinate subordinate;
// getter/setters
public void kickOff() {
System.out.println("I do something big");
subordinate.doSomethingBig();
subordinate.doSomethingSmall(4);
}
}
Results of calling kickOff above given code above.
I do something big
Doing the cross cutting concern now
I did something small
Doing the cross cutting concern now
I also do something small but with an int
but when you change your code to
#Component("mySubordinate")
public class CoreBusinessSubordinate {
public void doSomethingBig() {
System.out.println("I did something small");
doSomethingSmall(4);
}
public void doSomethingSmall(int x){
System.out.println("I also do something small but with an int");
}
}
public void kickOff() {
System.out.println("I do something big");
subordinate.doSomethingBig();
//subordinate.doSomethingSmall(4);
}
You see, the method internally calls another method so it won't be intercepted and the output would look like this:
I do something big
Doing the cross cutting concern now
I did something small
I also do something small but with an int
You can by-pass this by doing that
public void doSomethingBig() {
System.out.println("I did something small");
//doSomethingSmall(4);
((CoreBusinessSubordinate) AopContext.currentProxy()).doSomethingSmall(4);
}
Code snippets taken from:
https://www.intertech.com/Blog/secrets-of-the-spring-aop-proxy/
The page doesn't exist anymore.