9 Using Batching with Message-Driven Beans

Within an MDB, business logic, including database transactions, is performed within the onMessage() method. Within an EJB application, multiple MDBs can perform multiple onMessage() calls. If each onMessage() call performs a database transaction, this can create a lot of overhead where each call requires its own database connection.

WebLogic Server provides a mechanism for grouping onMessage() calls together as a single transaction. This mechanism can help increase database performance of an EJB application by grouping all of the transactions into a single I/O request. Grouping transactions allows requires fewer transaction logs.

For information on transaction management within MDBs, see Configuring Transaction Management Strategy for an MDB.


Transaction batching is not effective for all MDB applications. For example, database deadlocks can occur in an application where an MDB makes multiple calls to a database. Using the transaction batching feature will cause the MDB to lock more rows per transaction which can lead to database deadlocks.

Configuring MDB Transaction Batching

You can enable MDB transaction batching by defining the max-messages-in-transaction element. This element is part of the message-driven-descriptor element of the weblogic-ejb-jar.xml deployment descriptor.

max-messages-in-transaction defines the batch size WebLogic Server uses to process onMessage() transactions. However, increasing the batch size can increase latency. You should start with a small value, 5 for example. You can increase this value as your application performance allows.

When using MDB batching, more messages are processed per transaction. This may cause more transactions to time out since more work is being performed in each transaction. You can increase the transaction timeout be increasing the value of trans-timeout-seconds attribute of weblogic-ejb-jar.xml.

How MDB Transaction Batching Works

MDB transaction batching does not require any changes to application code. As far as the application is concerned, individual messages are still processed one by one. There is no application level message list.

Internally, WebLogic Server creates a queue to manage the transactions. Each message is queued until the number of messages in the queue is equal to the batch size defined by max-messages-in-transaction. However, if there is no next message to be queued, the current messages in the queue are submitted for processing.

If an individual onMessage() call fails, then the entire batch is rolled back. If the failure was due to a transaction timeout, as defined in the trans-timeout-seconds attribute of weblogic-ejb-jar.xml, the MDB container temporarily reduces the batch size and attempts to process the transactions with smaller batches.

If failure occurs for another reason, the MDB reprocesses each message within the failed batch as an individual transaction. This avoids the scenario where an individual onMessage() call can permanently hang an entire batch.