To expand on Sahoo's reply:
Context of the question really matters a lot. How much CPU are you spending on sending and receiving messages vs. doing something more interesting? How much memory?
Start with a profiler to make sure that you really are addressing the right problem and that the maintenance pain of managing your own cached JMS parts will pay off.
Sending a JMS message creates at least one new object every time (the message). Avoiding the creation of three others would buy at best a linear gain in a system that is very message-intensive. If you're trying for performance on a message-intensive system, be aware that you're on a slope away from JMS. Even SomnifugiJMS burns time on recovering unreferenced objects.
In practice, the Connection is the monster, and is safe to reuse unless you want to change its parameters while you're sharing the Connection. The Session and Sender are usually smaller. Those two are hard to reuse safely across multiple threads, and the JMS spec doesn't officially support it.
If you're using an application server, use the application server's cache of connections. Don't waste your energy writing your own cache. Instead read the docs and ask questions about how to configure your system to use someone else's cache.
[Message sent by forum member 'dwalend' (dwalend)]
http://forums.java.net/jive/thread.jspa?messageID=329667