JMS design Note

http://docs.oracle.com/cd/E12840_01/wls/docs103/jms/fund.html#nontransacted
JMS supports two messaging models: point-to-point (PTP) and publish/subscribe (pub/sub).

PTP
Multiple queue senders and queue receivers can be associated with a single queue, but an individual message can be delivered to only one queue receiver
listening for messages on a queue, WebLogic JMS determines which one will receive the next message on a first come, first serve basis. If no queue receivers are listening on the queue, messages remain in the queue until a queue receiver attaches to the queue.

Pub/Sub
Unlike with the PTP messaging model, the pub/sub messaging model allows multiple topic subscribers to receive the same message. JMS retains the message until all topic subscribers have received it.
The Pub/Sub messaging model supports durable subscribers, allowing you to assign a name to a topic subscriber and associate it with a user or application.

**Durable subscribers require a persistent store to be configured on their JMS server, even if they receive only non-persistent messages. A durable subscription is persisted to ensure that it continues through a server restart, as required by the JMS specification.

Message Persistence
A persistent message is guaranteed to be delivered once-and-only-once. The message cannot be lost due to a JMS provider failure and it must not be delivered twice. It is not considered sent until it has been safely written to a file or database.
Non-persistent messages are not stored. They are guaranteed to be delivered at-most-once, unless there is a JMS provider failure, in which case messages may be lost, and must not be delivered twice. If a connection is closed or recovered, all non-persistent messages that have not yet been acknowledged will be redelivered.

http://docs.oracle.com/cd/E12840_01/wls/docs103/jms/design_best_practices.html

Topics vs. Queues
Surprisingly, when you are starting to design your application, it is not always immediately obvious whether it would be better to use a Topic or Queue. In general, youshould choose a Topic only if one of the following conditions applies:

1. The same message must be replicated to multiple consumers.
2. A message should be dropped if there are no active consumers that would select it.
3. There are many subscribers, each with a unique selector.

It is interesting to note that  a topic with a single durable subscriber is semantically similar to a queue. The differences are as follows:

If you change a topic selector for a durable subscriber, all previous messages in the subscription are deleted, while if you change a queue selector for consumer, no messages in the queue are deleted.
A queue may have multiple consumers, and will distribute its messages in a round-robin fashion, whereas a topic subscriber is limited to only one consumer.

Asynchronous vs. Synchronous Consumers
In general, asynchronous (onMessage) consumers perform and scale better than synchronous consumers:

1. Asynchronous consumers create less network traffic. Messages are pushed unidirectionally, and are pipelined to the message listener. Pipelining supports the aggregation of multiple messages into a single network call.
   1. Note:In WebLogic Server, your synchronous consumers can also use the same efficient behavior as asynchronous consumers by enabling the Prefetch Mode for Synchronous Consumers option on JMS connection factories
2. Asynchronous consumers use fewer threads. An asynchronous consumer does not use a thread while it is inactive. A synchronous consumer consumes a thread for the duration of its receive call. As a result, a thread can remain idle for long periods, especially if the call specifies a blocking timeout.
3. For application code that runs on a server, it is almost always best to use asynchronous consumers, typically via MDBs. The use of asynchronous consumersprevents the application code from doing a blocking operation on the server. A blocking operation, in turn, idles a server-side thread; it can even cause deadlocks. Deadlocks occur when blocking operations consume all threads. When no threads remain to handle the operations required to unblock the blocking operation itself, that operation never stops blocking.

Asynchronous Message Pipeline

If messages are produced faster than asynchronous message listeners (consumers) can consume them,  a JMS server will push multiple unconsumed messages in a batch to another session with available asynchronous message listeners. These in-flight messages are sometimes referred to as the message pipeline

Configuring a Message Pipeline

You can control a client’s maximum pipeline size by configuring the  Messages Maximum per Session attribute on the client’s connection factory, which is defined as the “maximum number of messages that can exist for an asynchronous consumer and that have not yet been passed to the message listener”.  The default setting is 10.

Persistent vs. Non-Persistent Messages
When designing an application, make sure you specify that messages will be sent in non-persistent mode unless a persistent QOS is required. We recommend non-persistent mode because unless synchronous writes are disabled, a persistent QOS almost certainly causes a significant degradation in performance.

If your messages are truly non-persistent, none should end up in a regular JMS store. 

Deferring Acknowledges and Commits
Because sends are generally faster than receives, consider reducing the overhead associated with receives by deferring acknowledgment of messages until several messages have been received and can be acknowledged collectively. If you are using transactions substitute the word commit for acknowledge.

Client Side :http://chenjumin.iteye.com/blog/687124

 //事务性会话，自动确认消息  
        Session session = conn.createSession(true, Session.AUTO_ACKNOWLEDGE);  
          
        //消息的来源地  
        Destination destination = session.createQueue("queue.hello");  
          
        //消息消费者  
        MessageConsumer consumer = session.createConsumer(destination);  
        consumer.setMessageListener(this);  
          
        //等待接收消息  
        while(!stop){  
            Thread.sleep(5000);  
        }  
          
        session.commit(); 

public void onMessage(Message m) {  
        try{  
            if(m instanceof TextMessage){ //??????  
                TextMessage message = (TextMessage)m;  
                System.out.println(message.getText());  
            }else if(m instanceof MapMessage){ //???????  
                MapMessage message = (MapMessage)m;  
                System.out.println(message.getLong("age"));  
                System.out.println(message.getDouble("sarray"));  
                System.out.println(message.getString("username"));  
            }else if(m instanceof StreamMessage){ //?????  
                StreamMessage message = (StreamMessage)m;  
                System.out.println(message.readString());  
                System.out.println(message.readLong());  
            }else if(m instanceof BytesMessage){ //??????  
                byte[] b = new byte[1024];  
                int len = -1;  
                BytesMessage message = (BytesMessage)m;  
                while((len=message.readBytes(b))!=-1){  
                    System.out.println(new String(b, 0, len));  
                }  
            }else if(m instanceof ObjectMessage){ //??????  
                ObjectMessage message = (ObjectMessage)m;  
                User user = (User)message.getObject();  
                System.out.println(user.getUsername() + " _ " + user.getPassword());  
            }else{  
                System.out.println(m);  
            }  
              
            stop = true;  
        }catch(JMSException e){  
            stop = true;  
            e.printStackTrace();  
        }  
    }  
}  

http://www.4ucode.com/Study/Topic/1140187

public void onMessage(Message m) {
  try {
    Object command = new MessageHandler(m);
    process(command);
    topicSession.commit();
  } catch (MessageInvalidException e) {
    log(t);
    //我们不希望处理这个异常
    topicSession.commit();
  } catch (Throwable t) {
   log(t);
   topicSession.rollback();
  }
}

Alternative Qualities of Service, Multicast and No-Acknowledge

Using NO_ACKNOWLEDGE
A no-acknowledge delivery mode implies that the  server gives messages to consumers, but does not expect acknowledge to be called. Instead, the server pre-acknowledges the message. In this acknowledge mode, calls to recover will not work, as the message is already acknowledged. This mode saves the overhead of an additional network call to acknowledge,  at the expense of possibly losing a message when a server failure, a network failure, or a client failure occurs.

Note: If an asynchronous client calls close() in this scenario, all messages in the asynchronous pipeline are lost.

Note:If an asynchronous client calls close() in this scenario, all messages in the asynchronous pipeline are lost.
Asynchronous consumers that use a NO_ACKNOWLEDGE QOS may wish to tune down their  message pipeline size in order to reduce the number of lost messages in the event of a crash.

http://docs.oracle.com/cd/E15051_01/wls/docs103/jms_dotnet/guidelines.html#wp1078900
Transactions
In this release, the JMS .NET client supports transacted sessions as defined in the JMS Specification only. Transacted sessions provide a standard local transaction capability. As with the Java client, one or more WebLogic JMS destinations from within the same cluster may participate in a transacted session local transaction, but no other resources may participate (such as JMS servers in other clusters, databases, or foreign JMS providers).

Global XA transactions are not supported, therefore JMS cannot participatein a .NET transaction. The XA setting of the connection factory is ignored by the .NET client. The JMS NET client operations cannot participant in any .NET transactions.

Q & A

1. How can I receive batches of messages from a JMS Queue?

http://www.thatisjava.com/q/java-enterprise/24693/

A good JMS provider will already batch messages to a consumer under the covers. e.g. Apache ActiveMQ will batch deliver messages to a consumer up to a pre-defined prefetch value so that there is very little network traffic for each message as the message will already be in RAM ready for use.

from Riverlau: the answer is we can receive batches of messages , Prefetch and Asyn Message Pipeline in Async consumer and Prefetch mode in Sync consumer seem to be the same thing??(http://docs.oracle.com/cd/E12840_01/wls/docs103/jms/implement.html Using the Prefetch Mode to Create a Synchronous Message Pipeline)