JMS: Unit of Order Scope (Producer or Message) [WLS]

Question

Is it the intent of "Unit of Order" to be used at the Producer layer or at the message layer? The documentation seems to imply the former.
The documentation describes the method WLProducer.setUnitOfOrder(uooName). This implies that the intent is to set the Unit of Order name, and then send many messages within the Unit of Order.
I have a stream of messages that are mostly unrelated. Each message affects one entity, and the system has many (10s-of-thousands) entities. Unrelated messages can be processed in any sequence. However, every once in a while there are two messages for the same entity that are in close time proximity. These messages must be processed in sequence.
Since the Unit of Order is different for every message, the natural approach would be to set it in the send method. But WLS does not offer that.
The alternative is to call WLProducer.setUnitOfOrder( entityId) before each send. Would that be reasonable, or is that against the intent of Unit of Order?
Thanks...
Roger
PS: My appologies, I posted this in the wrong group. It relates to WEbLogic Server.
Message was edited by: rfischer
rfischer

Answer 1

I am assuming a single queue, non-Distributed Queue for this post, and that your CPU and memory for your WebLogic server have some headroom per queued message.
I agree that you should try UOO, if the server has enough memory headroom to accommodate Unit of Order data structures for the messages that are in the Queue.
There are some small coordination objects and the user defined string per UOO.
These objects are for the UOO messages that are currently in the queue rather than all the ones the server has ever encountered.
Though you may have tens of thousands of UOOs possible in your application, it sounds like a message for each one is probably not in the queue at the same time.
If you have a few hundred messages in the queue, and your server already has ample memory and CPU,
then adding the memory overhead of UOO is worth the investment for the correctness you get in return, see below.
If you really have tens of thousands of messages in the queue, and your server already has ample memory and CPU to accommodate the UOO objects,
then adding the memory overhead of UOO may still be worth the investment for the correctness you get in return.
The hard part here is the extra memory usage since UOO is not paged out the way message bodies are.
So you will have more memory use and Garbage Collection.
There is also more CPU since you have to look up the UOO when you produce the message.
This makes trying it more important before you go into production.
In both cases, you should certainly see less database lock and internal lock contention if your lock objects are related to your UOO names, since there will be only one thread in execution with that UOO name.
So you may see a database throughput improvement, which may be the heaviest part of your application.
Choosing the UOO name is always important, long enough to reduce contention, short enough to have as message payload and in memory.
I hope you post the results of your evaluation,
-Sal