JMS Section Index | Page 9
A message selector is a condition established for (attached to) a topic or queue by the consumer. The JMS server honors a consumer's message selector and does not deliver nonqualifying/filtered m...more
Can a publishing client ensure the order of message deliver for, say, five messages, by manipulating the priority of each message from, say, 5 to 1?
No. Message priority is considered by the JMS server and potentially overrides the default first-in-first-out (FIFO) message handling strategy. Priorities should be viewed as one factor that pot...more
No. Message durability ("durableness?") is established between a subscribing client (topic subscribers only, not queue receivers) and the JMS server on a topic-by-topic basic, that is, per subscr...more
How does message persistence affect the order of message production by a client and delivery by the JMS server?
It's convenient to view persistent and nonpersistent messages from the same producing client as elements of a partitioned space, even if sent to the same destination. There is no guarantee that a...more
What are the ramifications of having multiple consumers in one session for the same destination (queue or topic)?
The JMS server will provide only one instance of each message for a named destination per session. The issue of which consumer actually receives the message is implementation dependent. There is...more
Distributed transaction services are provided via the Java Transaction API (JTA). JMS does not mandate JTA support. See the JMS vendor's documentation for JTA-related discussion, especially, whe...more
In general, no. JMS guarantees that messages delivered by a server to a client, relative to a single destination and via a single session, are delivered in order. This order may be different fro...more
No. The specification does not support so-called subscription notification. Subscription notification is resource expensive and would place an unjustifiable burdensome on the JMS server. more
No. A client, in a single operation, cannot publish to a list of topics and it cannot send to multiple queues. A client must establish a message-producer object for each topic/queue and manually...more
Is it possible to use transacted sessions with other Java-technology, transaction processing facilities, for example, JTA?
No. It is possible (if provided by the JMS implementation) to use JTA in the context of a session, but not a transacted session. That is, you cannot use Session.commit() and Session.rollback() i...more
If a session is configured as transacted, how are independent, or nontransaction-related, messages handled?
Each client can create multiple sessions, with each session producing and/or consuming messages. Each session is independently configurable. (Note that each session should be closed gracefully t...more
Is it possible for a client to send multiple messages and ensure that the entire set of messages is delivered?
The preferred method for handling interdependent messages is to produce them within a transacted session. See Session.commit(), Session.rollback(), and XASession. more
Many publish/subscribe message systems support a tree-organized topic arrangement, many of which predate JMS. For example, suppose the server in question supports topic hierarchies and it is mana...more
If the JMS specification required a thread-safe implementation for all objects, it would, in many situations, be a burden on programmers. The following objects support concurrent use: Destinatio...more
The JMS specification does not require a security-related API and it does not address in detail the process/mechanism for administering objects that exist within a running JMS implementation. Thu...more