Compatibility for WLS 10.0 and Earlier-style Polling Tune the Number of Database Connections Waste Not

11-6 Performance and Tuning for Oracle WebLogic Server

11.6 Compatibility for WLS 10.0 and Earlier-style Polling

In WLS 10.0 and earlier, transactional MDBs with batching enabled created a dedicated polling thread for each deployed MDB. This polling thread was not allocated from the pool specified by dispatch-policy, it was an entirely new thread in addition to the all other threads running on the system. See Section 11.1, Use Transaction Batching . To override the token-based polling behavior and implement the WLS 10.0 and earlier behavior, you can either: ■ At the server level, set the weblogic.mdb.message.81StylePolling system property to True to override the token-based polling behavior. ■ At the MDB level, set the use81-style-polling element under message-driven-descriptor to override the token-based polling behavior. When using foreign transactional MDBs with the WLS 8.1-style polling flag, some foreign vendors require a permanently allocated thread per concurrent MDB instance. These threads are drawn from the pool specified by dispatch-policy and are not returned to the pool until the MDB is undeployed. Since these threads are not shared, the MDB can starve other resources in the same pool. In this situation, you may need to increase the number of threads in the pool. With the token-based polling approach for such foreign vendors, the threads internal JMS message consumer is closed rather than cached to assure that messages will not be reserved by the destination for the specific consumer. 12 Tuning Data Sources 12-1 12 Tuning Data Sources The following sections provide tips on how to get the best performance from your data sources: ■ Section 12.1, Tune the Number of Database Connections ■ Section 12.2, Waste Not ■ Section 12.3, Use Test Connections on Reserve with Care ■ Section 12.4, Cache Prepared and Callable Statements ■ Section 12.5, Using Pinned-To-Thread Property to Increase Performance ■ Section 12.6, Database Listener Timeout under Heavy Server Loads ■ Section 12.7, Disable Wrapping of Data Type Objects ■ Section 12.8, Use Best Design Practices

12.1 Tune the Number of Database Connections

A straightforward and easy way to boost performance of a data source in WebLogic Server applications is to set the value of Initial Capacity equal to the value for Maximum Capacity when configuring connection pools in your data source. Creating a database connection is a relatively expensive process in any environment. Typically, a connection pool starts with a small number of connections. As client demand for more connections grow, there may not be enough in the pool to satisfy the requests. WebLogic Server creates additional connections and adds them to the pool until the maximum pool size is reached. One way to avoid connection creation delays for clients using the server is to initialize all connections at server startup, rather than on-demand as clients need them. Set the initial number of connections equal to the maximum number of connections in the Connection Pool tab of your data source configuration. See JDBC Data Source: Configuration: Connection Pool in the Oracle WebLogic Server Administration Console Help. You will still need to determine the optimal value for the Maximum Capacity as part of your pre-production performance testing. For more tuning information, see Tuning Data Source Connection Pool Options in Configuring and Managing JDBC Data Sources for Oracle WebLogic Server.

12.2 Waste Not

Another simple way to boost performance is to avoid wasting resources. Here are some situations where you can avoid wasting JDBC related resources: 12-2 Performance and Tuning for Oracle WebLogic Server ■ JNDI lookups are relatively expensive, so caching an object that required a looked-up in client code or application code avoids incurring this performance hit more than once. ■ Once client or application code has a connection, maximize the reuse of this connection rather than closing and reacquiring a new connection. While acquiring and returning an existing creation is much less expensive than creating a new one, excessive acquisitions and returns to pools creates contention in the connection pool and degrades application performance. ■ Dont hold connections any longer than is necessary to achieve the work needed. Getting a connection once, completing all necessary work, and returning it as soon as possible provides the best balance for overall performance.

12.3 Use Test Connections on Reserve with Care