Spring beans are assumed to have the following classes
public class Service Implement iservice{
@Transactional (readOnly = False, propagation=propagation.required)
public void MethodA () {
.....
MethodB ()
......
}
@Transactional (readOnly = False, Propagation=propagation.requires_new)
public void methodb{
......
}
}
public class servicefacade{
@Autowired
private IService service;
pub Lic void Method () {
service.methoda () {
}
}
}
Ask Call Servicefacade Method () methods, what is the MethodA and MethodB business?
in the same transaction or two transactions, does the MethodA transaction take effect or does the METHODB transaction take effect?
The answer is that MethodA's transaction takes effect and MethodB is embedded into the MethodA to become a transaction.
why is that? MethodB's not a statement.propagation.requires_new?
The answer is that spring's transactions are implemented through an AOP dynamic proxy, starting with the spring transaction implementation.
generates a proxy for the bean. Because MethodB is called inside the service, the methodb of the agent Bean is not executed at this time, so the transaction declaration above METHODB is invalidated
when facade invokes the service's MethodA method, it actually executes Serviceproxy.methoda, so the method is taken over by the spring transaction. The transaction declaration takes effect.
The workaround is that the MethodB is placed in another bean by MethodA call or facade call Service.methoda () and then called Service.methodb
Summary: Spring's transactions are implemented based on an AOP dynamic agent. By default, a different method is called in the same class, and the above transaction declaration is not valid.
The above language may not be accurate, but that's probably what it means. If you have a better statement, please let me know, thank you.
A misconception about the use of spring transactions
