Область действия javax.jms.Queue в управляемом контексте

Я хотел бы знать, какова ожидаемая область действия javax.jms.Queue в управляемом контексте java EE.

Является ли хорошей практикой хранить ссылки на экземпляры Queue локально или я должен разрешать их каждый раз, когда отправляю сообщение.

Я полагаю, что сохранение ссылки лучше, чем множественный поиск jndi, поскольку вы часто видите такой код в bean-компонентах без сохранения состояния:

@Resource(lookup = "jms/QueueName")
private Queue queue;

Во всяком случае, в настоящее время у меня возникают проблемы (XA operation failed Cannot start, session is already doing work in a transaction XidImpl) с использованием кэшированных экземпляров Queue, разрешенных с помощью javax.jms.Session#createQueue("queueName").

Это приводит меня к другому вопросу: есть ли разница между разрешением очереди с помощью поиска jndi или с использованием Session#createQueue("queueName");


person Gab    schedule 30.01.2018    source источник
comment
Как вы думаете, почему локальный поиск JNDI стоит дорого?   -  person Steve C    schedule 30.01.2018
comment
Кто сказал, что местный?   -  person Gab    schedule 30.01.2018
comment
На что указывает jms/QueueName?   -  person Steve C    schedule 30.01.2018
comment
Это всего лишь пример. Как я уже сказал, очереди разрешаются не с помощью JNDI, а с помощью session#createQueue(queueName), ссылки сохраняются в concurrentHashMap и повторно используются позже с другими сеансами, код был здесь до меня, и я действительно не знаю, почему это было реализовано так   -  person Gab    schedule 30.01.2018
comment
Сервер JMS — это удаленный Jboss, который просто размещает кучу разных очередей JMS, клиент — это одноэлементный компонент Spring, который вручную просматривает локальную управляемую ConnectionFactory (да, приложение Spring, работающее в контейнере Java EE, не спрашивайте меня, почему :)   -  person Gab    schedule 30.01.2018
comment
Схему развертывания можно найти здесь:stackoverflow.com/questions/33500395/   -  person Gab    schedule 30.01.2018