This week's book giveaway is in the Jython/Python forum.
We're giving away four copies of Murach's Python Programming and have Michael Urban and Joel Murach on-line!
See this thread for details.
Win a copy of Murach's Python Programming this week in the Jython/Python forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic

JMS: which administered objects should be long-lived  RSS feed

 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'm working on a class within a webapp that serves as a JMS Message Producer. The architect of the project I'm working on has stated that all broker-administered objects (e.g. ConnectionFactory, Connect, Session, Destination/Queue) should be long-lived; i.e. instantiated on webapp start-up, and retained until the app is shut down.

Following the design of our home-spun framework, one instance of the class I am creating is loaded when the app server starts up, and that instace persists throughout the life of the app. Thus, the administered objects can be initialized once and stored as member variables to my class:


This instance is then used by various requests that come in to the webapp (presumably on different threads).

Well, I'm having problems on the second time the instance is executed, with an error message that the Session is closed. I don't explicitly close() the Session anywhere (that will be taken care of by a deconstructor, invoked from a Servlet destroy() method). In re-looking over some documentation, I'm now wondering if making all the administered objects long-lived is the right approach (as opposed to, say, creating a new Session on each execute() call).

Does anyone have any thoughts on which administered objects can/should be long-lived, and which can't/shouldn't?
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Usually objects like connection factory,queues, topics etc are bound to JNDI tree and the devloper isn't bothered about the life cycle. You can do a lookup when you need to use them. I suggest that you read Active MQ docs on how to bind to JNDI.
Connections , sessions are not administered objects and should be created only when required. Usually creating one connection object would suffice but session should be created per client as it is not thread safe.
 
Pradeep bhatt
Ranch Hand
Posts: 8933
Firefox Browser Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Move your session creation logic to execute ().
http://java.sun.com/j2ee/1.4/docs/api/javax/jms/Session.html
 
dave taubler
Ranch Hand
Posts: 132
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Prad,

Thanks for the reply. I'll definitely go back over the ActiveMQ docs regarding JNDI. I seem to recall that a fair amount of the ActiveMQ on the subjects of at least creating Destinations revolved around "don't worry about JNDI lookups, just create your Topics and Queues on the fly." But Connections and Sessions may be different.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!