utilizzando una sessione JMS da diversi thread

Question

Dal javadoc per Session afferma:

Un oggetto Session è un contesto thread singolo per la produzione e il consumo di messaggi.

così ho capito che non si dovrebbe usare un oggetto Session da due diversi thread allo stesso tempo. Quello su cui non sono chiaro è se si potesse usare l'oggetto Session (o child come una coda) da un thread diverso da quello creato.

Nel caso in cui sto lavorando, sto considerando di mettere i miei oggetti Session in un pool di sessioni disponibili che qualsiasi thread potrebbe prendere in prestito da, usare e tornare al pool quando è finito con esso.

È questo kosher?

(Usando ActiveMQ A proposito, se che gli impatti della risposta a tutti.)

Answer 1

Purtroppo le JMS documenti spesso non sono scritti nel modo più chiaro e preciso come si potrebbe piacere: o (

Ma leggendo le specifiche I 'm ora abbastanza convinto davvero non dovrebbe accedere alla sessione da altri thread, anche se si garantisce non c'è l'accesso simultaneo il bit del javadoc che oscillato per me era:.

volta che la connessione è stata avviata , qualsiasi sessione con un messaggio registrato listener (s) è dedicato alla discussione di controllo che recapita i messaggi a it. È errato che il codice client per utilizzi questa sessione o uno qualsiasi dei suoi oggetti costitutivi da un altro thread di controllo . L'unica eccezione è l'uso della sessione o il metodo di chiusura della connessione .

Nota l'uso chiaro di "thread of control" e l'individuazione di "close()" come unica eccezione.

Sembrano dire che anche se si utilizza il consumo di messaggi asincroni (ad esempio setMessageListener) - il che significa che viene richiamato su un altro thread creato da JMS per ricevere messaggi - non è mai consentito toccare la sessione o oggetti correlati di nuovo da qualsiasi altro thread, perché la sessione è ora 'dedicata' al thread di consegna JMS. Ad esempio, suppongo che questo non possa nemmeno chiamare message.acknowledge() da un altro thread.

Detto questo, ho appena notato che non abbiamo obbedito a questo vincolo e non abbiamo ancora notato alcun effetto negativo (utilizzando SonicMQ). Ma ovviamente se non obbedisci allo standard, tutte le scommesse sono fuori gioco, quindi suppongo che dobbiamo obbedire alla regola della sessione 1 a 1 thread per stare al sicuro.

Answer 2

Penso che la nota in calce dal paragrafo 4.4 in the JMS 1.1 spec getta una luce:

Non ci sono restrizioni sul numero di thread che possono utilizzare un oggetto Session o coloro che crea. La restrizione è che le risorse di una sessione non devono essere utilizzate contemporaneamente da più thread. Spetta all'utente assicurarsi che questa restrizione di concorrenza sia soddisfatta. Il modo più semplice per farlo è usare un thread.In caso di consegna asincrona, utilizzare un thread per l'installazione in modalità interrotta e quindi avviare la consegna asincrona. Nei casi più complessi, l'utente deve fornire una sincronizzazione esplicita.

Con la mia lettura delle specifiche, ciò che si desidera fare è OK, purché gestisca correttamente la concorrenza.