Perché le specifiche JMS sono progettate in modo che l'oggetto Session non possa essere utilizzato da thread simultanei quando l'oggetto Connection da cui vengono create le sessioni è thread-safe (Shared by thread)?Perché JMS Session Object non è thread-safe?
L'oggetto di sessione JMS viene in genere utilizzato per le transazioni. E sappiamo tutti che le transazioni sono specifiche del thread e non possono estendersi su thread. Quindi una sessione JMS negoziata non può essere utilizzata attraverso i thread. Credo che per questa ragione le specifiche JMS affermino che la sessione non è thread-safe.
JMS 2.0 Spec
pagina 25
Ci sono due ragioni per limitare l'accesso concorrente alle sessioni.
In primo luogo, le sessioni sono l'entità JMS che supporta le transazioni. È molto difficile da implementare le transazioni che sono multi-thread.
In secondo luogo, le sessioni supportano il consumo di messaggi asincroni. È importante che il JMS non richieda che il codice client utilizzato per il consumo di messaggi asincroni sia in grado di gestire più messaggi simultanei .
Inoltre, se una sessione è stata allestita con molteplici, consumatori asincroni, è importante che il cliente non è costretto per gestire il caso in cui questi consumatori sono separati in concomitanza esecuzione. Queste restrizioni rendono JMS più facile da usare per i tipici client . I clienti più sofisticati possono ottenere la concomitanza del desiderio utilizzando più sessioni. Nella classica API e nelle API specifiche del dominio significa utilizzare più oggetti di sessione. Nell'API semplificata significa utilizzare più oggetti JMSContext.
spiegazione interessante +1 –