pericoli di utilizzo di variabili ThreadLocal con EJB3?

Question

sto sperimentando una soluzione per l'autorizzazione e l'autenticazione, memorizzando una classe soggetto in una mappa ThreadLocal. Il progetto è per un'API, quindi non hanno accesso alle servlet coinvolti, e ho bisogno di usare EJB3 (quindi CDI non è un'opzione). Ho un paio di domande sull'utilizzo ThreadLocal con EJB3

1. Supponendo che ogni richiesta pulisce la sua mappa ThreadLocal dopo che è fatto, non v'è alcun rischio utilizzando una variabile ThreadLocal con bean di sessione senza stato? In altre parole, non v'è alcun rischio che due richieste possono accedere allo stesso thread nello stesso momento?

2. C'è un modo di far rispettare servlet per pulire la ThreadLocal dopo hanno finito? Ho guardato in intercettori, ma ho capito che funzionano male con EJB3, e il lavoro variamente bene in diversi server applicativi. Qualsiasi altro modo?

Answer 1

Per rispondere alla mia domanda, no, non con la sicurezza che sembra. Utilizzando una variabile ThreadLocal può funzionare se ho il controllo di tutto il processo, ma se l'avessi fatto allora potrei usare CDI och JSP per mantenere richiesta variabili locali.

Punti a tutti quelli che hanno risposto però.

Answer 2

Per quanto riguarda la risposta di Martin, vale la pena di notare che la primavera di Sicurezza stesso utilizza una ThreadLocal comunque di default ( SecurityContextHolder ), quindi sarei cauto sull'utilizzo di esso se è necessario il contesto di protezione per sopravvivere attraverso invocazioni EJB. Certamente non funzionerà attraverso invocazioni remote; si potrebbe con locale, ma non credo che ci siano garanzie.

In genere, quando si utilizza Primavera di sicurezza evito EJB e utilizzare il framework Spring per il cablaggio di un POJO di livello intermedio e per la fornitura di servizi come la demarcazione delle transazioni tramite AOP. Il contesto di protezione è quindi disponibile in tutto il livello intermedio come filo rimane lo stesso su tutta la chiamata.

Answer 3

mi consiglia di non utilizzare ThreadLocal in un contenitore EJB. Autorizzazione e autenticazione è una preoccupazione trasversale, io personalmente guardare usando qualcosa come AOP per questo (per esempio Come offerte di sicurezza di primavera con esso).