Use the standard JMS APIs to develop point-to-point messaging applications. This section helps identify how the micro broker implements some of the provider-specific parts of the JMS specification.
When a request is made to browse a queue, the micro broker will take a snapshot of messages on the queue at that time, and send a copy of all messages to the client. Any future updates are not reflected in the browser enumeration.
When putting messages on a queue using a transacted session, messages are held internally by the micro broker until a commit is issued. This means that all messages will be put onto the queue in one attempt, rather than based on when they were originally sent. For example, assume two clients, A and B, are putting messages to a queue. Each uses a transaction, and they are received by the broker in the order A1, B1, A2, B2, A3, B3. A commits, B commits. The order of messages on the queue will be: A1, A2, A3, B1, B2, B3. A consequence of this behavior is that a call to commit a session may lead to a QueueFullException
if there is not space on the destination queue. This exception will cause the transaction to be rolled back.
Parent topic: Developing a JMS application: XPD621