I was disappointed to learn that when getting a JMS connection more
than once in the same transaction, it actually consumes another
connection from the pool.
We do a lot of side affect event stuff in to JMS, and with a large
transaction, this can burn through connections at a pretty fast rate.
I came up with a way to mitigate it a little bit using a Stateful
Session Bean, and SessionSynchronization. But even with that, in the
end, I have the same issues of having to pass it around, since
whenever I ask for a new bean from JNDI, I get a new bean -- and a new
connection. But it does handle connection lifecycle, and closing the
connection properly, in a reasonably elegant manner.
In today's day and age of declarative properties, it sees quite
"creaky" to have to be passing around things like JMS connections in
order to conserve them.
What I would really like is something that lets me tie in to the
current transaction life cycle, then I can use a combination
singleton/threadlocal to cache the "current" JMS connection, and then
clean it up afterward.
I've tried using TransactionSynchronizationRegistry, but things get
out of sync and I get all sorts of transaction errors. I also tried
using TransactionSynchronizationRegistry.getTransactionKey() to use
that as a key to a map, but it too lead to problems. I contemplated
using the UserTranscation as a key, but JNDI won't even give me one in
a CMT environment (which is what I'm in).
I can't just use a raw ThreadLocal, because we do a lot of nested
transactions, so the connection needs to be mated with the current
transaction.
For now, I'm simply passing my Stateful Bean around, just like I did
back 15 years ago. I'm hoping there's a better solution. A GlassFish
specific vs a JEE solution would be fine, we have no plans on porting
this code to anything else anytime soon.
We're running GF 3.1.2.
Speaking of Stateful Beans, if I don't have a @StatefulTimeout, are
the beans automatically destroyed when the transaction
commits/rollsback?
Thanks for any thoughts on this.
Regards,
Will Hartung
(willh_at_mirthcorp.com)
--
This message, and any documents attached hereto, may contain confidential
or proprietary information intended only for the use of the addressee(s)
named above or may contain information that is legally privileged. If you
are not the intended addressee, or the person responsible for delivering it
to the intended addressee, you are hereby notified that reading,
disseminating, distributing or copying this message is strictly prohibited.
If you have received this message by mistake, please immediately notify us
by replying to the message and delete the original message and any copies
immediately thereafter. Thank you for your cooperation.