ThreadLocal + java.sql.Connection + фильтр сервлета = 2009?

Управление транзакциями Spring делает именно то, что вы описываете. нужно (для простейшего случая):

org.springframework.jdbc. datasource.DataSourceTransactionManager org.springframework.jdbc.datasource.TransactionAwareDataSourceProxy org.springframework.transaction.support.TransactionTemplate

Подключите свой существующий DataSource и оберните его в TransctionAwareDataSourceProxy, затем создайте DataSourceTransactionManager с обернутым источником данных, сохраните их в своем ServletContext. Затем для каждой транзакции создайте TransactionTemplate, передаваемый в диспетчере транзакций, и вызовите метод execute(TransactionCallback) для запуска вашего кода. например:

new TransactionTemplate(transactionManager).execute(new TransactionCallback(){
    public void doInTransaction(TransactionStatus ts){
        // run your code here...use the dataSource to get a connection and run stuff
        Connection c = dataSourceProxy.getConnection();
        // to rollback ... throw a RuntimeException out of this method or call 
        st.setRollbackOnly();
    }
});

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

Обратите внимание, что это простейшая возможная настройка транзакции Spring ... не совсем лучшая или рекомендуемая, для этого взгляните на справочный документ Spring или прочитайте Spring в действии.

... так что я думаю, как прямой ответ, да, это разумно, это то, что Spring Framework делает в течение длительного времени.

Большинство современных серверов приложений поддерживают JTA (Java Transaction Api): транзакцию, которая охватывает несколько открытых/закрытых соединений jdbc. Он выполняет за вас функции threadLocal и совместим с J2EE. Вы используете его так в своем фильтре:

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    throws IOException, ServletException {
    UserTransaction transaction = null;
    try {
        transaction = (UserTransaction)new InitialContext().lookup("java:comp/UserTransaction");
        transaction.begin();
        chain.doFilter(request, response);
        transaction.commit();
    } catch (final Exception errorInServlet) {
        try {
            transaction.rollback();
        } catch (final Exception rollbackFailed) {
            log("No ! Transaction failed !",rollbackFailed);
        }
        throw new ServletException(errorInServlet);
    }
}

На сервере приложений объявите источник данных с именем jndi и используйте его в своем коде для получения соединения (НЕ делайте cx.commit(), cx.rollback() или cx.setAutocommit(), это будет мешать с JTA). Вы можете открывать и закрывать соединение несколько раз в одной и той же HTTP-транзакции, JTA позаботится об этом:

public void doingDatabaseStuff() throws Exception {
    DataSource datasource = (DataSource)new InitialContext().lookup("/path/to/datasource");
    Connection connection = datasource.getConnection();
    try {
        // doing stuff
    } finally {
        connection.close();
    }
}

В общем случае лучше передать объект с "Параметризацией сверху", сглаживание с ThreadLocal. В случае ServletFilter очевидным местом будет атрибут ServletRequest. Интерфейс к коду, не зависящему от сервлета, может извлекать Connection в осмысленный контекст.

Если вы не можете полагаться на «настоящий» сервер приложений и хотите избежать не очень легковесности Spring, использование фильтра для обеспечения соединения, сохранения его в потоке и закрытия в конце запроса — это действительно практичное и разумное решение.

Вам понадобится некоторый (по существу статический) класс доступа, который позволяет получить () соединение и setRollbackOnly ().

По завершении запроса, с точки зрения фильтра, обязательно поймайте исключения (при которых вы должны зарегистрировать и установить только откат) и зафиксируйте/откатите, соответственно закройте транзакцию.

В большинстве приложений и веб-контейнеров (и JTA обычно делает аналогичные предположения) запрос будет обрабатываться ровно одним потоком, и привязка одного соединения к базе данных с потоком для повторного использования между уровнями во время запроса — это то, что нужно сделать.

Использование фильтра для управления транзакциями — хороший подход к развертыванию собственного управления транзакциями.

Спецификация Java EE обеспечивает управление транзакциями, и альтернативные платформы, такие как Spring, обеспечивают аналогичную поддержку (хотя это не одобрение; Spring не обязательно делает это хорошо).

Однако использование ThreadLocal может создать проблемы. Например, нет никаких гарантий, что во всем запросе используется один поток, что угодно может получить доступ к Connection через глобальную переменную, и тестирование может стать более сложным, если вы зависите от некоторого глобального состояния, которое нужно настроить. Я бы подумал об использовании контейнера внедрения зависимостей, чтобы явно передать Connection объектам, которым он нужен.