Actualmente estoy tratando con código donde hay un singleton que es usado por muchos subprocesos y no tiene ningún estado excepto dos campos para una TransactionTemplate y una SimpleJdbcTemplate que se usan en las funciones de singleton para acceder a la base de datos.¿La primavera TransactionTemplate y SimpleJdbcTemplate son seguros para subprocesos?
¿Esto es seguro o debo crear una nueva plantilla, siempre que la necesite?
SimpleJdbcTemplate simplemente envuelve una JdbcTemplate, por lo que it's thread-safe, como es the TransactionTemplate.
Actualy no. Ver el código fuente para la prueba. Como mínimo, TransactionTemplate tiene el miembro no final transactionManager que puede ser no visible en los subprocesos ya creados. Además, deriva todos los miembros no finales y públicamente mutables de DefaultTransactionDefinition.
En realidad, los contenedores dinámicos (como OSGI) bajo carga pueden obtener NPE en el uso del administrador de transacciones dentro de TransactionTemplate. Especialmente si crea TransactionTemplate en sí mismo (no según el contexto Spring). Esto se debe a que los subprocesos de trabajo (por ejemplo, los procesadores de solicitudes web) ya se han creado y son cálidos (tiene un caché de la CPU con destino propio). Cuando se crea una nueva plantilla de transacción en el hilo de inicio, no se ejecuta ningún obstáculo de memoria para vaciar el caché enlazado al hilo (o el núcleo del CPU). En casos muy raros, los miembros de TransactionTemplate de nueva creación pueden no ser visibles para hilos 'viejos'.
Nos encontramos con un error análogo (no exactamente con TransactionTemplate pero con RetryTemplate) en la producción después de la actualización del funcionamiento del servicio web. Es necesario decir que no vemos ese error en el caso de las instancias creadas de Spring Context, puede ser debido a la sincronización global realizada en la inicialización del contexto.
Casi todas las clases de plantillas de Spring son mutables y no tienen una sincronización explícita dentro. ¿Por qué la documentación dice que es el hilo de guardar? No entiendo.
Puede protegerse parcialmente finalizando el campo en su propia clase que contiene referencia a * Plantilla debido a esa declaración en JMM (ver enlace adjunto): "Además, los valores visibles para cualquier otro objeto o matriz referenciado por esos campos finales estarán al menos tan actualizados como los campos finales ".
En ese caso, si no cambia el estado de la * instancia de la plantilla, es "thread safe". No por el diseño de la clase en sí, sino por el uso específico y las propiedades de JMM.
+1 para hacer referencia a la documentación real ... – pap