Dlaczego specyfikacje JMS zostały zaprojektowane tak, aby obiekt sesji nie mógł być używany przez współbieżne wątki, gdy obiekt połączenia, z którego tworzone są sesje, jest bezpieczny dla wątków (udostępniany przez wątek)?Dlaczego obiekt sesji JMS nie jest bezpieczny dla wątków?
Obiekt sesji JMS jest zwykle używany do transakcji. Wszyscy wiemy, że transakcje są specyficzne dla wątków i nie mogą obejmować całego wątku. Dlatego transakcja JMS transakcji nie może być używana w wątkach. Wierzę, że z tego powodu specyfikacja JMS mówi, że sesja nie jest bezpieczna dla wątków.
JMS 2.0 Spec
strona 25
Istnieją dwa powody, dla ograniczenia jednoczesnego dostępu do sesji.
Po pierwsze, sesje są jednostką JMS obsługującą transakcje. To bardzo trudne do zrealizowania transakcje wielowątkowe.
Po drugie, sesje obsługują asynchroniczne zużycie wiadomości. Ważne jest, aby JMS nie wymagał, aby kod klienta używany do asynchronicznego przesyłania komunikatów był w stanie obsłużyć wiele jednoczesnych komunikatów: .
Ponadto, jeśli sesja została utworzona z wielu, asynchronicznych konsumentów, ważne jest, że klient nie jest zmuszony obsłużyć przypadek, gdy te osobne konsumenci są jednocześnie wykonywania. Te ograniczenia powodują, że JMS jest łatwiejszy w użyciu dla typowych klientów o numerach . Bardziej wyrafinowani klienci mogą uzyskać pożądaną współbieżność, korzystając z wielu sesji. W klasycznych interfejsach API i związanych z domenami oznacza to używanie wielu obiektów sesji. W uproszczonym interfejsie API oznacza to użycie wielu obiektów JMSContext.
interesujące wyjaśnienie +1 –