J2EE.6.6 One JMS session per connection and code portability
Hello,
Section J2EE.6.6 of the J2EE 1.4 spec states that "Application
components in the web and EJB containers must not attempt to
create more than one active (not closed) Session object per connection."
This is contrary to the API documentation for javax.jms.Connection that
states "Because the creation of a connection involves setting up
authentication and communication, a connection is a relatively
heavyweight object. Most clients will do all their messaging with a
single connection." (Indeed I found that e.g. JBoss creates seven
threads for each connection that I create in a client).
I want to provide a library that encapsulates the required calls to
setup several JMS sessions. Given the above, this library must act
differently when run within and outside an EJB container. Is there a
portable way to determine in one's code whether the code is running
inside or outside an EJB container?
Regards,
Michael Lipp
[1027 byte] By [
MLippa] at [2007-11-26 19:08:27]
# 2
The point is that the JMS API documentation (and all secondary articles on this) recommends to create only one connection in the client container and use it for all concurrent sessions. From the JavaDoc: "Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection."
And indeed, if you look e.g. at JBoss you'll find that is creates several threads for each JMS connection created in the client container. So it is really advisable to re-use the connection for all sessions.
Even reading it again, I find this situation definitely different from the requirement to create a new connection for each session when I am in the EJB or web container. Of course, I can close a session and re-use the connection, but in my case I need quite a number of concurrently open sessions!
# 3
The EJB or servlet will not create its own connection, it will request one from the application server.
The application server maintains a pool of connections and returns one of them to your component, possibly creating a new one for you if no connections are available.
That's exactly the same as the inner workings of JDBC connection pooling.
The session is a shortlived entity retrieved from the connection for the duration of a method call, just as you'd close a PreparedStatement when you're done with it in a JDBC application even if you were going to keep the connection alive for later use.
You're worrying too much about semantics here. The client here is NOT JBoss, it's your EJB or servlet which polls JBoss for a connection as required.
As those connections are pooled you can just return them to the pool when you're done with them.
The warning about cost is mainly there for JMS clients running outside an application server which would have to do their own creation and destruction of connections, just as with JDBC.
# 4
Thanks very much for your responses. You miss, however, a very important point. Maybe I didn't emphasize this point enough in my original posting.
I want to write a client library with a "SomeServiceFactory" that creates a "SomeService". "SomeService" happens to require several concurrent topic sessions. But this requirement is to be hidden from the user of the service. And the supplied library should be usable both in a "client container" (i.e. a stand-alone client) and in an EJB or web container (with an EJB or Servlet making use of "SomeService").
So "SomeService" must behave differently when creating sessions, depending on whether it runs in the client container or an EJB or web container. Of course I can request the user/developer to specify some configuration file/option depending on the environment -- and then I can pray not to get too much problem reports because developers will simply forget to specify the environment as required or get things wrong.
Or I can find a way to automatically find out about the environment my library is used in and everybody is happy -- hence my original question.
