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 takes a snapshot of messages on the queue at that time and sends 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 approach means that all messages are 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 is: A1, A2, A3, B1, B2, B3. A consequence of this behavior is that a call to commit a session can lead to a QueueFullException
if there is not space on the destination queue. This exception causes the transaction to be rolled back.
Parent topic: Developing a JMS application: XPD622