Permite hacer algunas declaraciones básicas.
- Un contexto transaccional es un entorno donde algunas propiedades especiales (sesión de la base de datos) están disponibles para el tiempo de ejecución de la aplicación que de otro modo no estarían disponibles. Un contexto de transacción generalmente se usa para determinar el alcance de una transacción.
- Spring usa, AOP Proxies y metadatos XML para lograr una gestión de transacciones declarativa.
- Las anotaciones se utilizan para marcar el comportamiento de Propagación de transacción de un método en particular.
- Spring usa Interceptor Mechanism para aplicar la transacción sobre los métodos.
Aquí estoy reutilizando el ejemplo anterior da por @stacker
MyClass{
@Transactional
public void sequence() {
method1();
method2();
}
@Transactional
void method1() {
}
@Transactional(propagation=Propagation.REQUIRES_NEW)
void method2() {
}
}
También puede conseguir la misma funcionalidad utilizando la configuración de XML también. Tomemos esto como su popular y ampliamente utilizado.
En el momento de despliegue
- framework Spring comprueba los archivos de configuración xml (famosa
applicationContext.xml
) y dependiendo de la configuración, escanea el código para @Transactional
anotación (suponiendo que la configuración se menciona como la anotación de base).
- Después de esto, genera proxies AOP para los métodos marcados para la transacción. En términos simples, estos proxies no son más que envoltorios alrededor de los métodos involucrados.
- Dentro de estos métodos de envoltura, antes y después de también se genera el código del Asesor de transacciones según la configuración (es decir, la propagación de la transacción).
- Ahora, cuando se invocan estos métodos de contenedor Transacción Asesor entra en la imagen antes y después de la llamada al método real. .
En representación de la misma en pseudo código para el ejemplo anterior
ProxyMyClass{
MyClass myclass;
.
.
.
sequence(){
//Transaction Advisor code (Typically begin/check for transaction)
myclass.sequence();
//Transaction Advisor code(Typically rollback/commit)
}
.
.
.
}
Esto es cómo los gerentes de primavera la transacción. Sin embargo, una ligera simplificación excesiva.
Ahora para responder a sus preguntas,
.How sabe primavera para confirmar las actualizaciones de bases de datos en una transacción exitosa? ¿Hay alguna referencia a la implementación de Spring que haga la gestión de transacciones?
Siempre que llame a un método bajo transacción, realmente llama a un proxy que primero ejecuta el asesor de transacción (que iniciará la transacción), luego llama al método de negocio real, una vez que se completa, se ejecuta otro asesor de transacción (que dependiendo del método de camino devuelto, se comprometerá o revertirá la transacción).
Dado que tenemos una jerarquía de transacciones: Transacción alrededor de la web-solicitud-> Transacción con propagación = SolicitudNuevo para Método1-> Transacción con propagación = Requerido para Método2, ¿cómo hace Spring la gestión de transacciones para garantizar que las transacciones ejecutado dentro del contexto adecuado con el orden correcto?
En el caso de la jerarquía de transacción, el marco de resorte genera los controles Transacción Advisor en consecuencia. Para el ejemplo que mencionas,
- para method1 (RequestNew) El código de Transaction Advsor (o Transaction Advice) sería crear siempre una nueva transacción.
- para el código metodo2 (Obligatorio) Asesor de Transacción (o consejos transacción) sería comprobar la transacción existente y utilizar la misma si existe o bien crear una nueva transacción.
Hay un image on the spring documentation page que muy bien resume estos aspectos.
Espero que esto ayude.
, esta fue una explicación increíble. Gracias –
¿Puede explicar si en el diagrama anterior la persona que llama es un controlador o una solicitud web? – tintin
@tintin, no importa si la persona que llama es el controlador o cualquier otra cosa. Al final será una llamada de método de alguna clase a proxies. – Santosh