WebLogic Server Performance and Tuning

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Tuning Message-Driven Beans

The following sections provide tuning and best practice information for Message-Driven Beans (MDBs):


Use Transaction Batching

MDB transaction batching allows several JMS messages to be processed in one container managed transaction. Batching amortizes the cost of transactions over multiple messages and when used appropriately, can reduce or even eliminate the throughput difference between 2PC and 1PC processing. See Transaction Batching of MDBs in Programming WebLogic Enterprise JavaBeans.

Note: Using batching may require reducing the number of concurrent MDB instances. If too many MDB instances are available, messages may be processed in parallel rather than in a batch. See MDB Thread Management.
Note: While batching generally increases throughput, it may also increase latency (the time it takes for an individual message to complete its MDB processing).


MDB Thread Management

Thread management for MDBs is described in terms of concurrency—the number of MDB instances that can be active at the same time. The following sections provide information on MDB concurrency:

Determining the Number of Concurrent MDBs

Table 10-1 provides information on how to determine the of concurrently running MDB instances for a server instance.

Table 10-1 Determining Concurrency for WebLogic Server MDBs 
Type of work manager or execute queue
Default work manager or unconstrained work manager
varies due to self-tuning, up to Min(max-beans-in-free-pool,16)
Default work manager with self-tuning disabled
Min(default-thread-pool-size/2+1, max-beans-in-free-pool)

Note: This is also the default thread pool concurrency algorithm for WebLogic Server 8.1

Custom execute queue
Custom work manager with constraint
varies due to self-tuning, between min-thread-constraint and Min(max-threads-constraintmax-beans-in-free-pool)

Transactional MDBs with batching enabled create a dedicated polling thread for each deployed MDB. This polling thread is not allocated from the pool specified by dispatch-policy, it is an entirely new thread in addition to the all other threads running on the system. See Use Transaction Batching.

Selecting a Concurrency Strategy

The following section provides general information on selecting a concurrency stategy for your applications:

Note: Every application is unique, select a concurrency stategy based on how your application performs in its environment.


Using Foreign Vendor MDBs

The following sections provide information on the behavior of WebLogic Server when using foreign vendor MDBs:

Determining Concurrency for Foreign MDBs

When using foreign MDBs, WebLogic Server determines conccurency as shown in Table 10-2.

Table 10-2 Determining Concurrency for Foreign Vendor MDBs
Tuning Factor
Information Reference
Same algorithm as for WebLogic MDBs
Topic: Non-transactional
Concurrency is always one.
Topic: Transactional
Same algorithm as for WebLogic MDBs.

Thread Utilization When Using Foreign MDBs

The following section provides information on how threads are allocated when WebLogic Server interoperates with foreign vendor MDBs:

Note: When using foreign transactional MDBs, 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.

  Back to Top       Previous  Next