I seem to recall having a similar issue using the WebSphere 5.1 Embedded JMS Server. It
has been about 3 years or more so I am not crystal clear on all the details. I has a
stateless session bean that I used to send JMS messages from a third party process engine
as part of a global transaction. I needed to close the session after each message was sent
because the WebSphere Embedded JMS Server was not thread safe, i.e. if one thread sent a
message on the same session as a second message on another thread, the JMS server might
get confused and throw an exception. But when I closed the session in the finally clause,
the message did not get sent, because the transaction had not been commited.
The solution in this case was to make the JMS session an instance variable and close it
the next time the session bean method was invoked, and then create a new session each
time.
I guess my point is the "Jo dumb user" may need to close the session, to
conserve resources or some other reason but has little control / knowledge of when the
global transaction is going to commit.
jBPM and hibernate have a similar issue. jBPM would typically tell hibernate to close the
hibernate session when the jbpmContext is closed. Fortunately jbpm has a configuration
option that can turn off this behavior in a managed environment. HIbernate also has
configuration options to auto close session after transaction commits.
It might be nice if there were a JMS server configuration option to say 'defer closing
sessions until transaction commits' or something similar. That way the choice can be
specified by the user, although I would vote to make this the default, since I think that
most often with a user closes the session, they still expect the message to be sent.
View the original post :
http://www.jboss.com/index.html?module=bb&op=viewtopic&p=3995959#...
Reply to the post :
http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&a...