2-20 Programming JMS for Oracle WebLogic Server
A server session pool is a WebLogic-specific JMS feature that enables you to process messages concurrently. A server session pool factory is used to create a server-side
ServerSessionPool.
WebLogic JMS defines one ServerSessionPoolFactory object, by default: weblogic.jms.extensions.ServerSessionPoolFactory:name, where
name specifies the name of the JMS server to which the session pool is created. The WebLogic Server adds the default server session pool factory to the JNDI space during
startup and the application subsequently retrieves the server session pool factory using WebLogic JNDI.
To learn how to use the server session pool factory within an application, see Section A.1, Defining Server Session Pools,
or the weblogic.jms.extnesions.ServerSessionPoolFactory Javadoc.
2.4.8 ServerSessionPool
A ServerSessionPool application server object provides a pool of server sessions that connection consumers can retrieve in order to process messages concurrently.
A ServerSessionPool is created by the ServerSessionPoolFactory object see Section 2.4.7, ServerSessionPoolFactory
obtained through a JNDI lookup. To learn how to use the server session pool within an application, see
Section A.1, Defining Server Session Pools,
or the javax.jms.ServerSessionPool Javadoc at http:java.sun.comjavaee5docsapijavaxjmsServerSessionPoo
l.html .
2.4.9 ServerSession
A ServerSession application server object enables you to associate a thread with a JMS session by providing a context for creating, sending, and receiving messages.
A ServerSession is created by a ServerSessionPool object, described in Section 2.4.8, ServerSessionPool.
To learn how to use the server session within an application, see Section A.1, Defining
Server Session Pools, or the javax.jms.ServerSession Javadoc at
http:java.sun.comjavaee5docsapijavaxjmsServerSession.ht ml
.
2.4.10 ConnectionConsumer
A ConnectionConsumer object uses a server session to process received messages. If message traffic is heavy, the connection consumer can load each server session with
multiple messages to minimize thread context switching. A ConnectionConsumer is created by a Connection object, described in
Section 2.4.2, Connection. To learn how to use the connection consumers within an application, see
Section A.1, Defining Server Session Pools,
or the javax.jms.ConnectionConsumer Javadoc at
http:java.sun.comjavaee5docsapijavaxjmsConnectionConsum er.html
.
Note: Connection consumer listeners run on the same JVM as the
server.
3
Best Practices for Application Design 3-1
3
Best Practices for Application Design
These sections discuss design options for WebLogic Server JMS, application behaviors to consider during the design process, and recommended design patterns.
■
Section 3.1, Message Design
■
Section 3.2, Message Compression
■
Section 3.3, Message Properties and Message Header Fields
■
Section 3.4, Message Ordering
■
Section 3.5, Topics vs. Queues
■
Section 3.6, Asynchronous vs. Synchronous Consumers
■
Section 3.7, Persistent vs. Non-Persistent Messages
■
Section 3.8, Deferring Acknowledges and Commits
■
Section 3.9, Using AUTO_ACK for Non-Durable Subscribers
■
Section 3.10, Alternative Qualities of Service, Multicast and No-Acknowledge
■
Section 3.11, Avoid Multi-threading
■
Section 3.12, Using the JMSXUserID Property
■
Section 3.13, Performance and Tuning
3.1 Message Design
This section provides information on how to design messages improve messaging performance:
3.1.1 Serializing Application Objects
The CPU cost of serializing Java objects can be significant. This expense, in turn, affects JMS Object messages. You can offset this cost, to some extent, by having application
objects implement java.io.Externalizable, but there still will be significant overhead in marshalling the class descriptor. To avoid the cost of having to write the
class descriptors of additional objects embedded in an Object message, have these objects implement Externalizable, and call readExternal and writeExternal
on them directly. For example, call obj.writeExternalstream rather than stream.writeObjectobj. Using Bytes and Stream messages is generally a
preferred practice.
