Проблемы с параллелизмом в Spring DAO с 3.0.0.RC1

Question

После обновления с 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 на com.mysql.jdbc.PreparedStatement.fillSendPacket (PreparedStatement.java:2439)"
• «java.util.ConcurrentModificationException в java.util.LinkedHashMap $ LinkedHashIterator.nextEntry (Unknown Source) "
• „org.hibernate.LazyInitializationException: незаконный доступ к коллекции загрузки“
• и т.д ...

Раньше я определить _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> 

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

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

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

Приветствия

Nik

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

PPS, вот нить, что заставило меня понять, я уже не мог определить _authenticationManager: SpringSource Forum Post

Answer 1

Кажется, что у меня была большая проблема в сессии базы данных обработки в моей DAO, так что я сделал write-up of my problem and posted the solution in another thread here at StackOverflow и попросил мнение людей о решении. Я надеюсь, что это не дает больше вопросов :-)

Приветствиях

Nik