Il thread HttpSession è sicuro, sono impostate/ottenute operazioni thread safe Attribute?

Question

Inoltre, l'oggetto che si sta impostando deve essere thread-safe per garantire che sappiamo quale sia lo stato dell'oggetto memorizzato nella sessione.

Inoltre, stavo leggendo sul web che utilizza alcuni suggeriscono:

synchronized(session) { 
    session.setAttribute("abc", "abc"); 
} 

È questo un suggerimento valido?

Answer 1

No, non sono thread-safe, secondo IBM - Java theory and practice: Are all stateful Web applications broken?. Devi sincronizzare.

How HttpSession is not thread safe da Java Ranch potrebbe essere utile.

Answer 2

No. E dal momento che non si desidera che lo stesso cliente (con sessione) di fare richieste simultanee, si dovrebbe serializzare queste richieste come il AbstractController fa in Spring MVC

Answer 3

In un certo senso, questo dipende dalla vostra progettazione del cliente.

Avete la possibilità, nel vostro web design, per un singolo cliente di avere più richieste simultanee in sospeso utilizzando la stessa sessione HTTP? Questo sembra difficile da fare se non si lega una singola sessione HTTP a più socket. (aka, AJAX) In breve, l'accesso HTTP di un determinato client sarà a thread singolo per quanto riguarda il server, il che significa che una singola sessione è effettivamente thread safe.

La sincronizzazione degli oggetti di sessione renderà l'applicazione più sicura rispetto alle modifiche future che rendono la tua applicazione Web capace di avere più richieste simultanee, quindi non è una cattiva idea. Nelle moderne implementazioni Java, la sincronizzazione non ha il grande costo che era precedentemente associato ad esso, specialmente quando la sincronizzazione di solito non era contenuta. Se la tua applicazione utilizza AJAX, il che implica che ti aspettano più richieste simultanee in volo sul tuo server web, allora la sincronizzazione è un must.

Answer 4

La sessione non è thread-safe e il metodo get non è impostato come sicuro. In generale in un contenitore di servlet si dovrebbe assumere di essere in un ambiente multi-thread e nessun tool fornito è sicuro.

Questo vale anche per gli oggetti memorizzati nella sessione. La sessione stessa non manipolerà l'oggetto memorizzato ma puoi recuperare l'oggetto in thread diversi e tentare di manipolarlo. Spetta a te esaminare il tuo codice per vedere se le condizioni di gara sono possibili.

L'esempio di codice pubblicato è valido, ma il problema potrebbe esistere oltre lo scopo limitato del tuo esempio. Assicura che non ci siano condizioni durante l'impostazione della sessione, ma non c'è nulla che impedisca ad un altro thread di sovrascrivere il set. Se il codice nella richiesta dipende dal valore che rimane invariato, potresti comunque essere nei guai.

Answer 5

Servlet 2.5 spec:

più servlet esecuzione richiesta discussioni possono avere accesso attivo allo stesso oggetto sessione di allo stesso tempo. Il contenitore deve garantire che la manipolazione dei dati interni delle strutture interne strutture che rappresentano gli attributi della sessione venga eseguita in modo threadthread-safe. Lo sviluppatore ha il la responsabilità per il threadsafe accesso agli oggetti attributo .Ciò proteggerà la collezione di attributi all'interno dell'oggetto HttpSession dall'accesso simultaneo , eliminando l'opportunità per un'applicazione che causa la corruzione della raccolta .

Questo è sicuro:

// guaranteed by the spec to be safe 
request.getSession().setAttribute("foo", 1); 

Questo è non sicura:

HttpSession session = request.getSession(); 
Integer n = (Integer) session.getAttribute("foo"); 
// not thread safe 
// another thread might be have got stale value between get and set 
session.setAttribute("foo", (n == null) ? 1 : n + 1); 

Questo è non garantita per essere al sicuro:

// no guarantee that same instance will be returned, 
// nor that session will lock on "this" 
HttpSession session = request.getSession(); 
synchronized (session) { 
    Integer n = (Integer) session.getAttribute("foo"); 
    session.setAttribute("foo", (n == null) ? 1 : n + 1); 
} 

Ho visto questo ultimo approccio sostenuto (incluso nei libri J2EE), ma non è garantito che funzioni secondo le specifiche Servlet. Si potrebbe use the session ID to create a mutex, ma ci deve essere un approccio migliore.

Answer 6

Non lo sono, ma la maggior parte delle volte, i tuoi clienti potranno accedervi solo con un singolo thread.

Diversi client avranno thread diversi e ognuno avrà una propria sessione.

Come sottolinea Eddie, una situazione in cui è possibile riscontrare due thread che accedono alla stessa sessione è che due chiamate Ajax stanno tentando di modificare lo stesso attributo di sessione. Altrimenti non avrai problemi.