¿Varias instancias de JdbcTemplate o no?

Question

Por lo que entiendo, tanto DataSource y JdbcTemplates son threadsafe, por lo puede configurar una sola instancia de un JdbcTemplate y luego inyectar de forma segura esta referencia compartida en múltiples DAO (o repositorios). También DataSource debe ser un singleton de primavera, ya que administra el grupo de conexiones.

El funcionario Spring Documentation JdbcTemplate best practices explica las alternativas (extractos del manual están en cursiva, y mis notas entre corchetes:

• configurar un origen de datos en el archivo de configuración de la primavera, y entonces la dependencia a inyectar que comparte origen de datos bean en sus clases DAO; la JdbcTemplate se crea en la incubadora para el DataSource [con la configuración de XML y esto conduce a varias instancias JdbcTemplate, ya que en el colocador fuente de datos hay new JdbcTemplate(dataSource)]
• uso componente de exploración y a. nnotation support para la inyección de dependencia. En este caso, anote la clase con @Repository (que lo convierte en candidato para el escaneo de componentes) y anote el método de configuración DataSource con @Autowired. [también este caso conduce a varias instancias de JdbcTemplate]
• Si usa la clase JdbcDaoSupport de Spring, y sus diversas clases DAO respaldadas por JDBC se extienden desde allí, su subclase hereda un método setDataSource (..) del Clase JdbcDaoSupport Puede elegir heredar de esta clase. La clase JdbcDaoSupport se proporciona solo como una conveniencia. [puesto que ya has una instancia de JdbcDaoSupport para cada clase de extenderlo, existe una instancia de JdbcTemplate demasiado para cada instancia de la clase derivada (ver source code for JdbcDaoSupport)]

Sin embargo, una nota posterior, desalienta toda la opciones recién presentadas:

Una vez configurada, una instancia de JdbcTemplate es segura para la rosca. Es posible que desee varias instancias JdbcTemplate si su aplicación accede a múltiples bases de datos, lo que requiere múltiples DataSources, y posteriormente múltiples JdbcTemplates configuradas de forma diferente.

En otras palabras, todas las opciones se acaban de presentar se traducirá en tener varias instancias JdbcTemplate (uno por DAO), y justo después de la documentación dice que no es necesario cuando se trabaja con una sola base de datos.

Lo que haría es inyectar directamente JdbcTemplate a los diversos DAO que lo necesitan, entonces mi pregunta es, ¿está bien hacerlo? Y también, ¿también crees que la documentación de referencia de Spring es contradictoria? ¿O es mi malentendido?

Answer 1

IMO, no hay ningún problema para inyectar JdbcTemplate en sus (múltiples) DAO (s). La plantilla se usa para "cablear" su DAO al recurso físico (conexión db) cuando necesita ejecutar la consulta db. Por lo tanto, si SessionFactory y TransactionManager están configurados correctamente, no se encontrará con problemas de concurrencia: Spring administra el ciclo de vida de los beans que necesita para trabajar con su capa de persistencia. Las ventajas de utilizar una plantilla son:

1. La plantilla JDBC gestiona los recursos físicos necesarios para interactuar con el DB automáticamente, p. crear y liberar las conexiones de la base de datos.
2. La plantilla Spring JDBC convierte las excepciones JDBC SQLE estándar en RuntimeExceptions.Esto le permite reaccionar de manera más flexible a los errores. La plantilla de Primavera también JDBC convierte los mensajes de error específicos del proveedor en los mensajes de error más comprensibles

Answer 2

por lo que deberá ser derramado dos situaciones:

no cambiamos propiedades JdbcTemplate en DAO, se puede definir de la siguiente manera:

<bean id="tlmJDBCTemplate" class="org.springframework.jdbc.core.JdbcTemplate"    <property name="dataSource" ref="plmTlmDataSource"/>   
    </bean> 

NOTA: La mayoría de las veces no cambiamos las propiedades de JdbcTemplate, porque no es necesario.

Cambiamos las propiedades de JdbcTemplate en DAO, deberíamos extender JdbcDaoSupport.

State: 
• fetchSize: If this variable is set to a non-zero value, it will be used for setting the fetchSize property on statements used for query processing(JDBC Driver default) 
• maxRows: If this variable is set to a non-zero value, it will be used for setting the maxRows property on statements used for query processing(JDBC Driver default) 
• queryTimeout: If this variable is set to a non-zero value, it will be used for setting the queryTimeout property on statements used for query processing.(JDBC Driver default) 
• skipResultsProcessing: If this variable is set to true then all results checking will be bypassed for any callable statement processing. This can be used to avoid a bug in some older Oracle JDBC drivers like 10.1.0.2.(false) 
• skipUndeclaredResults: If this variable is set to true then all results from a stored procedure call that don't have a corresponding SqlOutParameter declaration will be bypassed. All other results processing will be take place unless the variable {@code skipResultsProcessing} is set to {@code true}(false) 
• resultsMapCaseInsensitive: If this variable is set to true then execution of a CallableStatement will return the results in a Map that uses case insensitive names for the parameters if Commons Collections is available on the classpath.(false) 

1. JdbcDaoSupport

   clase abstracta pública JdbcDaoSupport extiende DaoSupport {

   private JdbcTemplate jdbcTemplate; 
   
   
   /** 
   * Set the JDBC DataSource to be used by this DAO. 
   */ 
   public final void setDataSource(DataSource dataSource) { 
       if (this.jdbcTemplate == null || dataSource != this.jdbcTemplate.getDataSource()) { 
        this.jdbcTemplate = createJdbcTemplate(dataSource); 
        initTemplateConfig(); 
       } 
   } 
   

   Resumen

: No creo que la primavera dan en la práctica guía es la mejor.

Answer 3

La primavera inherentemente es muy sutil sobre las mejores prácticas.

JdbcTemplate es seguro para la ejecución de subprocesos, notablemente bloqueable (v4.2.4). Lo que significa que no debe causar degradación del rendimiento cuando se comparte entre subprocesos concurrentes *. Por lo tanto, no hay razones de peso para más de una instancia por fuente de datos.

Nota especulativa: esta sección es realmente confusa. Probablemente debido a razones históricas (evolutivas). Tal vez la primavera tenía una política por día en el pasado debido a la seguridad de no hilo o la comprensión deficiente de dominio a la vez. Similar a la configuración basada en xml "desastre". Hoy en día, la primavera renuncia a las opiniones obstinadas y se esfuerza por ser flexible en su lugar. Lo cual, lamentablemente, provocó que las malas elecciones de diseño se reconocieran de forma encubierta.

_{* medida no adivine}