Проблемы параллелизма в Spring DAO с 3.0.0.RC1 - PullRequest
1 голос
/ 23 октября 2009

После обновления с Spring 3.0.0.M4 до 3.0.0.RC1 и Spring Security 3.0.0.M2 до 3.0.0.RC1 мне пришлось использовать тег security: authentication-manager вместо определения _authenticationManager, как я использовал в M4 / M2. Я приложил все усилия, чтобы определить это, и закончил с этим:

<security:authentication-manager alias="authenticationManager">
  <security:authentication-provider user-service-ref="userService">
    <security:password-encoder hash="plaintext"/>
  </security:authentication-provider>
</security:authentication-manager>

Когда я выполняю свои модульные тесты по одному, это прекрасно работает, и для большинства запросов AJAX это тоже хорошо работает, но, по-видимому, случайно, я получаю странные ошибки в моих транзакциях, когда моя сессия базы данных закрывается на полпути работа. Я могу спровоцировать эти ошибки, просто отправив множество разных AJAX-запросов на разные контроллеры от одного и того же клиента, тогда по крайней мере один из них произойдет сбой случайным образом. В следующий раз я попытаюсь, что один из них будет работать, а другой не получится.

Ошибка чаще всего возникает в моем userDAO, но также довольно часто в других DAOS, и исключения включают, как минимум, следующее:

  • "java.sql.SQLException: операция не разрешена после закрытия ResultSet"
  • "org.hibernate.impl.AbstractSessionImpl: errorIfClosed (): Сессия закрыта!"
  • "java.lang.NullPointerException at com.mysql.jdbc.PreparedStatement.fillSendPacket (PreparedStatement.java:2439)"
  • "java.util.ConcurrentModificationException at java.util.LinkedHashMap $ LinkedHashIterator.nextEntry (Неизвестный источник)"
  • "org.hibernate.LazyInitializationException: недопустимый доступ к загрузке коллекции"
  • и т.д ...

Раньше я использовал для определения bean-компонента _authenticationManager, и те же самые запросы работали как шарм. Но с RC1 мне больше не разрешено это определять. Раньше это выглядело так:

<bean id="_authenticationManager" class="org.springframework.security.authentication.ProviderManager">
  <property name="providers">
    <list>
      <bean class="org.springframework.security.authentication.dao.DaoAuthenticationProvider">
        <property name="userDetailsService" ref="userService"/>
        <property name="passwordEncoder">
          <bean class="org.springframework.security.authentication.encoding.PlaintextPasswordEncoder" />
        </property>
      </bean>
    </list>
  </property>
</bean>

Правильно ли я определил свою безопасность: менеджер аутентификации, чтобы он разделял транзакции для нескольких запросов от одного и того же клиента? Должен ли я определить это по-другому, или я должен определить другую безопасность: бобы?

Есть ли что-то, что я неправильно понял, что закрывает мои сеансы базы данных? В моей голове каждый запрос имеет свою базу данных подключения и транзакции. Все методы получения и установки являются синхронизированными, поэтому у меня действительно не должно быть проблем с параллелизмом. Все контроллеры REST, к которым пользовательский интерфейс обращается с запросами, являются GET-запросами и выполняют работу только для чтения. Насколько мне известно, ни один INSERT / UPDATE / DELETE не выполняется во время любого из этих запросов, и я проверил журналы базы данных, чтобы убедиться в этом.

Я с нетерпением жду ваших предложений о том, как избежать этих условий гонки.

Приветствия

Nik

PS, мой, я обновил вопрос, чтобы быть более конкретным, что проблема с безопасностью: менеджер аутентификации (или мне так кажется, если у вас есть советы, что это может быть что-то еще, что было бы здорово) что я вынужден использовать вместо моего собственного _authenticationManager, начиная с 3.0.0.RC1

PPS, вот тема, которая заставила меня понять, что я больше не могу определить _authenticationManager: Сообщение на форуме SpringSource

1 Ответ

0 голосов
/ 27 октября 2009

Похоже, у меня была большая проблема с обработкой сеансов базы данных в моем DAO, поэтому я сделал запись моей проблемы и разместил решение в другом потоке здесь, в StackOverflow , и попросил мнение людей о решении. Я надеюсь, что это не дает больше проблем: -)

Приветствия

Nik

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...