Problemi di concorrenza nei DAO di primavera con 3.0.0.RC1

Question

Dopo aver effettuato l'aggiornamento da Spring 3.0.0.M4 a 3.0.0.RC1 e Spring Security 3.0.0.M2 a 3.0.0.RC1, ho dovuto usare un tag security: authentication-manager invece di definire un _authenticationManager come facevo in M4 / M2. Ho fatto del mio meglio per definirlo, e ho finito con questo:

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

Quando eseguo i test delle unità uno alla volta, questo funziona benissimo, e per la maggior parte delle richieste AJAX funziona anche bene, ma apparentemente in modo casuale, ottengo strani errori nelle mie transazioni in cui la mia sessione di database sembra chiudersi a metà strada in il lavoro. Il modo in cui posso provocare questi errori è semplicemente l'invio di molte richieste AJAX diverse ai miei diversi controller dallo stesso client, quindi almeno uno di questi fallirà a caso. La prossima volta che provo, quello funzionerà e l'altro fallirà.

L'errore si verifica più frequentemente nel mio userDAO, ma anche abbastanza frequentemente in altri DAOS e le eccezioni includono almeno quanto segue:

• " java.sql.SQLException: operazione non consentita dopo la chiusura di ResultSet "
• " org.hibernate.impl.AbstractSessionImpl: errorIfClosed (): la sessione è chiusa! "
• " java.lang.NullPointerException su com.mysql.jdbc.PreparedStatement.fillSendPacket (PreparedStatement.java:2439) "
• " java.util.ConcurrentModificationException su java.util.LinkedHashMap $ LinkedHashIterator.nextEntry (fonte sconosciuta) "
• " org.hibernate.LazyInitializationException: accesso illegale al caricamento della raccolta "
• ecc ...

Prima, ero solito definire un bean _authenticationManager e le stesse richieste funzionavano come un incantesimo. Ma con RC1, non mi è più permesso di definirlo. Sembrava così:

<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>

Ho definito la mia sicurezza: gestore dell'autenticazione in modo errato in modo che condividerà le transazioni per più richieste dallo stesso client? Dovrei definirlo diversamente, o dovrei definire qualche altra sicurezza: bean?

C'è qualcosa che ho frainteso che fa chiudere le sessioni del mio database? Nella mia testa, ogni richiesta ha una propria connessione al database e transazione. Tutti i getter e setter sono metodi sincronizzati, quindi non dovrei avere problemi di concorrenza. Tutti i controller REST contro cui l'interfaccia utente invia richieste sono richieste GET e funzionano in sola lettura. Per quanto ne sappia, non viene eseguito un singolo INSERT / UPDATE / DELETE durante nessuna di queste richieste e ho verificato i log del database per verificarlo.

Non vedo l'ora di ricevere i tuoi suggerimenti su come evitare queste condizioni di gara.

Saluti

Nik

PS, ho aggiornato la domanda per essere più specifico che il problema riguarda la sicurezza: autenticazione-gestore (o almeno così mi sembra, se hai suggerimenti che potrebbe essere qualcos'altro che sarebbe fantastico) che sono costretto a utilizzare al posto del mio _authenticationManager a partire da 3.0.0.RC1

PPS, ecco il thread che mi ha fatto capire che non potrei più definire un _authenticationManager: Post sul forum SpringSource

Answer 1

Sembra che ho avuto un grosso problema nella gestione delle sessioni di database nel mio DAO, quindi ho fatto un stesura del mio problema e ha pubblicato la soluzione in un altro thread qui su StackOverflow e ha chiesto l'opinione della gente sulla soluzione. Spero che non dia più problemi :-)

Saluti

Nik