Persistent vs. Non-Persistent Messages

3-4 Programming JMS for Oracle WebLogic Server ■ 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. ■ For application code that runs on a server, it is almost always best to use asynchronous consumers, typically via MDBs. The use of asynchronous consumers prevents 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. For more information, see Section 5.4.1, Receiving Messages Asynchronously and Section 5.4.2, Receiving Messages Synchronously.

3.7 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. To make sure that none of your messages are unintentionally persistent, check whether the JMS store size grows when unconsumed messages are accumulating on the JMS server. Here is how message persistence is determined, in order of precedence: ■ Producers connections connection factory configuration: – PERSISTENT default – NON_PERSISTENT ■ JMS Producer API override on QueueSender and TopicPublisher: – setDeliveryModeDeliveryMode.PERSISTENT – setDeliveryModeDeliveryMode.NON_PERSISTENT – setDeliveryModeDeliveryMode.DEFAULT_DELIVERY_MODE default ■ JMS Producer API per message override on QueueSender and TopicPublisher: – for queues, optional deliveryMode parameter on send – for topics, optional deliveryMode parameter on publish ■ Override on destination configuration: – Persistent – Non-Persistent – No-Delivery default, implies no override ■ Override on JMS server configuration: Note: Take special care to avoid persisting messages unintentionally. Occasionally an application sends persistent messages even though the designer intended the messages to be sent in non persistent mode. Best Practices for Application Design 3-5 – No store configured implies using the default persistent store that is available on each targeted WebLogic Server instance – Store configured implies no-override. ■ Non-durable subscribers only: – If there are no subscribers, or there are only non-durable subscribers for a topic, the messages will be downgraded to non-persistent. Because non-durable subscribers exist only for the life of the JMS server, there is no reason to persist the message. ■ Temporary destinations: – Because temporary destinations exist only for the lifetime of their host JMS server, there is no reason to persist their messages. WebLogic JMS automatically forces all messages in a temporary destination to non-persistent. 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.

3.8 Deferring Acknowledges and Commits