The following sections provide tuning and best practice information for Message-Driven Beans (MDBs):
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.
Notes: |
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:
Table 10-1 provides information on how to determine the of concurrently running MDB instances for a server instance.
|
|||
Transactional WebLogic MDBs use a synchronous polling mechanism to retrieve messages from JMS destinations if they are either: A) listening to non-WebLogic queues; or B) listening to a WebLogic queue and transaction batching is enabled. See Token-based Message Polling for Transactional MDBs Listening on Queues.
The following section provides general information on selecting a concurrency strategy for your applications:
Note: | Every application is unique, select a concurrency strategy based on how your application performs in its environment. |
min-threads-constraint
or by using a custom execute queue. max-threads-constraint
parameter and a high fair share setting. Note: | You must configure the max-threads-constraint parameter to override the default concurrency of 16. |
The following section provides information on how threads are allocated when WebLogic Server interoperates with WebLogic destinations.
dispatch-policy
as needed when there are new messages to be processed. If the MDB has successfully connected to its source destination, but there are no messages to be processed, then the MDB will use no threads.dispatch-policy
. See Token-based Message Polling for Transactional MDBs Listening on Queues.For information on how threads are allocated when WebLogic Server interoperates with foreign vendor MDBs, see Thread Utilization When Using Foreign MDBs.
The following sections provide information on the behavior of WebLogic Server when using foreign vendor MDBs:
When using foreign MDBs, WebLogic Server determines concurrency as shown in Table 10-2.
The following section provides information on how threads are allocated when WebLogic Server interoperates with foreign vendor MDBs:
dispatch-policy
is ignored except for determining concurrency.dispatch-policy
. See Token-based Message Polling for Transactional MDBs Listening on Queues.
Transactional WebLogic MDBs use a synchronous polling mechanism to retrieve messages from JMS destinations if they are either: A) listening to non-WebLogic queues; or B) listening to a WebLogic queue and transaction batching is enabled. With synchronous polling, one or more WebLogic polling threads synchronously receive messages from the MDB’s source destination and then invoke the MDB application’s onMessage
callback.
As of WebLogic 10.3, the polling mechanism changed to a token-based approach to provide better control of the concurrent poller thread count under changing message loads. In previous releases, the thread count ramp-up could be too gradual in certain use cases. Additionally, child pollers, once awoken, could not be ramped down and returned back to the pool for certain foreign JMS providers.
When a thread is returned to the thread pool with token-based polling, the thread’s internal JMS consumer is closed rather than cached. This assures that messages will not be implicitly pre-fetched by certain foreign JMS Providers while there is no polling thread servicing the consumer.
In addition, each MDB maintains a single token that provides permission for a given poller thread to create another thread.
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 Use Transaction Batching.
To override the token-based polling behavior and implement the WLS 10.0 and earlier behavior, you can either:
Note: | 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. |
Note: | With the token-based polling approach for such foreign vendors, the thread’s internal JMS message consumer is closed rather than cached to assure that messages will not be reserved by the destination for the specific consumer. |