JMS Notes

PTP Messaging:

1. Only one receiver. Queues
2. Needs acknowledgement. Messages will be persistent till the acknowledgement is received by the sender.
3. Receiver can go down and come back up, and the message will still be there.

Publish/Subscriber:

1. Can be any number of receivers 0*. Topics
2. Needs no acknowledgement. Messages will be persistent till all subscribed 'active' receivers receive message.
3. Only 'active' are receivers that are up will receive message. If non active receivers do need the messages too, then they can go for durable subscriptions.

TIPS:

1. A non-j2ee jms client application can use transactions for jms messages. These transactions are not meant to be used for request-reply scenario, rather they can be used for a series of send requests or a series of receive requests on a session and for a combination of requests and replies on different sessions.
2. A j2ee jms client application can use JTA or container managed transactions. For bean managed transaction, the messages are not redelivered when a transaction rollsback, whereas for container managed transaction messages are redelivered after a transaction rollback.
3. Message Driven Bean (MDB), does not have a remote or home interface. It has a setMessage- DrivenContext method. MDB differs from a regular JMS client, in a sense that most of the code required to initiate the message queues/sessions is automated for MDB, via deployment declarations. A MDB has to implement MessageListener and MessageDrivenBean interfaces.
4. If a SessionBean or Entity bean wish to be a client for the JMS, they should create the Connection resource in the ejbCreate() and release it in ejbRemove() methods. Create the Session in the business method, then close the resource in finally method. For stateful and entity beans close the sessions in ejbPassivate() and create them again in ejbActivate().
5. A session bean or entity bean should not block on a receive call as it will affect the performance of the ejb container.

Performance vs Reliability:

For performance reasons reliablity need be compromised. For applications where reliability is not a primary concern, and where it is affordable to loose some messages, like in performance data collection or statistics collection, it is advisable to use the following performance improvements:

1. Use delivery mode to be NON_PERSISTENT. JMS Provider by default uses persistent mode so that messages will be delivered even in the case of failure of the JMS provider. This is acheived by saving the messages to a log file. By specifying non_persistent mode, this overhead can be eliminated, hence improving performance.
2. Use time to live parameter that can specified either in MessageProducer interface or long form of pubish method to expire messages after certain interval. The default value of '0' implies messages will never expire.
3. To have variable response times for messages with varying priorities, use priorities for messages.
4. Set transaction attribute to "false" for sessions.