Set - 2

Question 26 :

What happens if acknowledge() is called within a transaction?

Answer :

As per the JMS specification, when you are in a transaction, the acknowledgeMode is ignored. If acknowledge() is called within a transaction, it is ignored.

Question 27 :

Is it possible to set aside a message and acknowledge it later?

Answer :

There are no special primitives for doing this. Here are two possible solutions.
One approach is to use multiple sessions as in the following:
while (true) {
Create a session, subscribe to one message on durable
Close session
Save session reference in memory
To acknowledge the message, find the session reference and call
acknowledge() on it.

Another solution is to use transactions and suspend the work as follows:
start transaction
while(true) {
message = receive();
if (message is one that I can handle)
process the message
} else {
suspend transaction
put transaction aside with message
start transaction

To "acknowledge" the message:
resume user transaction

To "recover" the message:
resume user transaction

Each time you suspend, you need to push the transaction onto a stack or list possibly with the message so you can process it or roll it back later. This solution is high overhead in that there can be a large build up of outstanding transactions. Note that transactions have timeouts and it may rollback on its own, which means you can get the message again (in a different transaction). Note also that there are some practical limits on the number of transactions you should leave outstanding. The default limit is something like 10000. Eventually you want to go back to your stack/list and commit/rollback the transactions. Note that transaction references (javax.transaction.Transaction) are not Serializable.

Question 28 :

How should I use sorted queues?

Answer :

Destination keys are used to define the sort order for a specific destination. Destination keys can be message header or property fields. For a list of valid message header and property fields, refer to the Programming WebLogic JMS.
Queues can be sorted in ascending or descending order based on the destination key. A destination is considered to be first-in-first-out if a destination key is defined as ascending for the JMSMessageID message header field, and last-in-first-out if defined as descending. The key defined for the JMSMessageID header field, if specified, must be the last key defined in the list of keys.
You can define multiple destination keys to sort a destination.

Question 29 :

How does sorting on message priority work?

Answer :

First, you need to add a key to the destination (by default, they are not sorted), choosing JMSPriority as the key. If you want 0 to be your highest priority, make the key ascending. If you want 9 to be the highest priority, make the key descending.
Second, the priority must be set using either the producer or on the send, not the message.
Third, the priority sorting only comes into play if there are multiple messages waiting on the queue. If the receiver is always caught up with the sender, then the messages will be processed in the order in which they come in.

Question 30 :

How do I get a thread dump to help track down a problem?

Answer :

Ways to get a thread dump:
* Try running this from the command line (after running the setEnv script in /bea/wlserver6.1/config/mydomain/):

java weblogic.Admin -url t3://localhost:7001 THREAD_DUMP

* On Windows, from the console window, enter Ctrl+Break.
* On UNIX, signal the server using kill -3.