java - create - setlayout jpanel
¿Cuál es la diferencia entre definir @Transactional en el método clase vs (4)
Citando de here
La recomendación del equipo de Spring es que solo anote las clases concretas con la anotación @Transactional, en lugar de anotar las interfaces.
Como este mecanismo se basa en proxies, solo se interceptarán las llamadas a métodos ''externos'' que entren a través del proxy. Esto significa que la "auto invocación", es decir, un método dentro del objeto objetivo que llama a otro método del objeto objetivo, no dará lugar a una transacción real en el tiempo de ejecución, incluso si el método invocado está marcado con @Transactional.
Caso 1
@Transactional
public class UserServiceImpl implements UserService {
...................
public void method1(){
try{
method2();
}catch(Exception e){
}
}
public void method2(){
}
}
Case2
public class UserServiceImpl implements UserService {
...................
public void method1(){
try{
method2();
}catch(Exception e){
}
}
@Transactional
public void method2(){
}
}
En caso 1 si ocurre alguna excepción, la reversión está funcionando, pero en el caso 2 no está funcionando. ¿Hay algún problema de rendimiento si sigo el caso1?
En caso de que 1 @Transactional se aplique a cada método individual. En el caso 2 @Transactional solo se aplica al método2 (), no en el método1 ()
Caso 1: - Invocar method1 () -> se inicia una transacción. Cuando method1 () llama a method2 () no se inicia ninguna transacción nueva, porque ya hay una
Caso 2: - Invocar method1 () -> no se inicia ninguna transacción. Cuando method1 () llama a method2 () NO se inicia ninguna transacción nueva. Esto se debe a que @Transactional no funciona cuando se llama a un método desde dentro de la misma clase. Funcionaría si llamaras a method2 () desde otra clase.
Del manual de referencia de primavera :
En el modo proxy (que es el predeterminado), solo se interceptan las llamadas a métodos externos que ingresan a través del proxy. Esto significa que la auto invocación, en efecto, un método dentro del objeto objetivo que llama a otro método del objeto objetivo, no conducirá a una transacción real en el tiempo de ejecución, incluso si el método invocado está marcado con @Transactional. Además, el proxy debe estar completamente inicializado para proporcionar el comportamiento esperado, por lo que no debe confiar en esta característica en su código de inicialización, es decir, @PostConstruct.
Supongamos que tiene la siguiente clase:
@Transactional(readOnly = true)
public class DefaultFooService implements FooService {
public Foo getFoo(String fooName) {
// do something
}
// these settings have precedence for this method
@Transactional(readOnly = false, propagation = Propagation.REQUIRES_NEW)
public void updateFoo(Foo foo) {
// do something
}
}
La anotación @Transactional en el nivel de clase se aplicará a todos los métodos de la clase.
Sin embargo , cuando un método se anota con @Transactional (como, updateFoo(Foo foo) ), esto tendrá prioridad sobre la configuración transaccional definida en el nivel de clase.
Más información:
@Transactional en una clase se aplica a cada método en el servicio. Es un atajo. Normalmente, puede establecer @Transactional(readonly = true) en una clase de servicio, si sabe que todos los métodos accederán a la capa de repositorio. A continuación, puede anular el comportamiento con @Transactional en los métodos que realizan cambios en su modelo. Problemas de rendimiento entre 1) y 2) no conocidos.