Несколько экземпляров JdbcTemplate или нет?

Из того, что я понимаю, оба DataSource и JdbcTemplates являются threadsafe, поэтому вы можете настроить один экземпляр JdbcTemplate, а затем безопасно ввести эту общую ссылку в несколько DAO (или хранилищ). Кроме того, DataSource должен быть синглетом Spring, так как он управляет пулом соединений.

Официальная Spring Документация JdbcTemplate лучшие практики объясняет альтернативы (выдержки из руководства выделены курсивом, а мои заметки между квадратными скобками:

сконфигурируйте DataSource в конфигурационном файле Spring, а затем иждитет-впрыскивайте совместно используемый DataSource bean в свои классы DAO; JdbcTemplate создается в установщике для DataSource. [с конфигурацией XML, и это приводит к нескольким экземплярам JdbcTemplate, поскольку в наборе источников данных есть new JdbcTemplate(dataSource)]
используйте компонентную проверку и поддержку аннотаций для инъекций зависимостей. В этом случае вы аннотируете класс с помощью @Repository (что делает его кандидатом на компонентное сканирование) и аннотирует метод setSource DataSource с помощью @Autowired. [также этот случай приводит к нескольким экземплярам JdbcTemplate]
Если вы используете класс Spring JdbcDaoSupport, и ваши различные классы DAO, поддерживаемые JDBC, расширяются от него, то ваш подкласс наследует метод setDataSource (..) из класса JdbcDaoSupport. Вы можете выбрать, следует ли наследовать этот класс. Класс JdbcDaoSupport предоставляется только для удобства. [поскольку у вас есть экземпляр JdbcDaoSupport для каждого расширяемого класса, для каждого экземпляра производного класса есть экземпляр JdbcTemplate (см. исходный код для JdbcDaoSupport)]

Однако, более поздняя заметка, препятствует всем представленным параметрам:

После настройки экземпляр JdbcTemplate является потокобезопасным. Возможно, вам понадобится несколько экземпляров JdbcTemplate, если ваше приложение обращается к нескольким базам данных, для чего требуется несколько источников данных, а затем несколько разных настроенных JdbcTemplates.

Другими словами, все предоставленные параметры приведут к тому, что несколько экземпляров JdbcTemplate (по одному на DAO) и сразу после того, как документы скажут, что это не обязательно при работе с одной базой данных.

Что бы я делал, это прямое вложение JdbcTemplate в различные DAO, которые нуждаются в этом, так что мой вопрос: нормально ли это делать? Кроме того, вы также считаете, что справочная документация Spring является противоречивой? Или мое недоразумение?

Ответ 1

IMO, нет необходимости вводить JdbcTemplate в ваш (несколько) DAO (s). Шаблон используется для "подключения" вашего DAO к физическому ресурсу (соединение db), когда вам нужно выполнить запрос db. Поэтому, если SessionFactory и TransactionManager настроены правильно, вы не столкнетесь с проблемами concurrency - Spring управляет жизненным циклом beans, который вам нужен для работы с вами. Преимущества использования шаблона:

Шаблон JDBC управляет физическими ресурсами, необходимыми для взаимодействия с БД автоматически, например. создавать и выпускать подключения к базе данных.
Шаблон JDBC Spring преобразует стандартные JDBC SQLExceptions в RuntimeExceptions. Это позволяет вам более гибко реагировать на ошибки. Шаблон Spring JDBC преобразует также сообщения об ошибках конкретного поставщика в более понятные сообщения об ошибках

Ответ 2

поэтому должно быть пролито две ситуации:

Мы не изменяем свойства JdbcTemplate в DAO, мы можем определить, как показано ниже:

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

ПРИМЕЧАНИЕ. В большинстве случаев мы не изменяем свойства JdbcTemplate, потому что это необязательно.

Мы изменяем свойства JdbcTemplate в DAO, мы должны расширять 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)

JdbcDaoSupport

открытый абстрактный класс JdbcDaoSupport расширяет 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();
    }
}

summary: Я не думаю, что spring дает практическое руководство в лучшем виде.

Ответ 3

По своей сути spring очень тонко описывает лучшие практики.

JdbcTemplate является потокобезопасным, особенно блокируемым (v4.2.4). Это не должно приводить к ухудшению производительности при совместном использовании параллельных потоков *. Таким образом, нет никаких веских причин для более чем одного экземпляра на источник данных.

Спекулятивное примечание: этот раздел действительно запутан. Вероятно, из-за исторических (эволюционных) причин. Может быть, spring имел в прошлом политику дао в связи с небезопасной безопасностью или плохим пониманием домена за раз. Подобно xml-конфигурации "катастрофа". В настоящее время spring отказываются от упрямых взглядов и стараются быть гибкими. Который, к сожалению, привел к тому, что плохой выбор дизайна был признан только скрытно.

_{* меру не угадать}