|
Problem |
InfoCenter reports that MaxSessions Needs to be set to "1"
for XA Transactions, so when using JMS-MDB:s. Does WebSphere support
concurrent message handling when using XA-transactions? |
|
Cause |
Maximum sessions
Specifies the maximum number of concurrent sessions that a listener can
have with the JMS server to process messages.
Each session corresponds to a separate listener thread and therefore
controls the number of concurrently processed messages. Adjust this
parameter when the JMS server does not fully use the available capacity of
the machine and if you do not need to process messages in a specific
message order.
Data type |
Integer |
Units |
Sessions |
Default |
1 |
Range |
1 through 2147483647 |
Recommended |
- If you want to process messages in a strict message order,
set the value to 1, so only one thread is ever processing messages.
- If you want to process multiple messages simultaneously
(known as "message concurrency"), set this property to a value greater
than 1. Keep this value as low as possible to prevent overloading client
applications. A good starting point for a 100% JMS workload with short
transaction times is 2 to 4 sessions per processor. If longer running
transactions exist, you may need more sessions, which should be determined
by experimentation. If you are using XA transactions, this property should
always be set to 1. If this property is set to a higher value, multiple
messages are delivered to the same transaction, which is usually not the
desired behavior.
|
If you are using XA transactions, this property should always be set to 1.
If this property is set to a higher value, multiple messages are delivered
in the same transaction, which is usually not the desired behavior. |
|
Solution |
The "Maximum Messages" property determines the number of
messages that will be processed within a single transaction. The default
value of this property is 1, which means that the transaction will be
committed when a message-driven bean (MDB) has processed a single message.
If you increase this value to 5, the MDB will have to process 5 messages
before the transaction will be committed. If the MDB has not processed 5
messages before the transaction timeout has been reached, the messages
will be rolled back to the queue they came from.
The "Maximum Sessions" property defines the number of messages that can be
processed concurrently by an MDB. The default value of this property is
also 1, meaning that an MDB can only process one message at a time. If you
increase this value to 5, then the MDB will be able to process up to 5
messages simultaneously.
How do these properties work together?
Suppose that both the "Maximum Messages" and "Maximum Sessions" properties
are both set to 5. This means that an MDB has to process 5 messages before
a transaction can be committed, but can handle up to 5 messages at the
same time. Therefore, if there are 5 messages on the queue at the time the
MDB starts up, it will immediately retrieve all of the messages from the
queue and start processing. When all 5 messages have been processed, the
transaction will be committed.
However, because the value of "Maximum Sessions" has been set to 5, the
application server is now doing 5 times the work. This may mean that the
transaction will timeout before all of the messages have been processed!
Therefore, if XA transactions are being used, we recommend that the
"Maximum messages" property is set to 1. This ensures that we only process
a single message per transaction, which reduces the possibility of
transaction timeouts. The value of "Maximum Sessions" should be tailored
depending on the customer's system - ideally, this property should be set
to a value that enables the MDB to process messages simultaneously without
the transaction timeout value being reached for individual messages.
If the customer wishes to process more than one message in a transaction,
then the value of "Maximum Sessions" should also be adjusted to ensure
that, if the MDB is processing the maximum number of messages
concurrently, the load on the system does not slow it down enough so that
transaction timeouts occur. |
|
|