| Managed Connection, manages one or more JMS sessions.
Every ManagedConnection will have a physical JMSConnection under the
hood. This may leave out several session, as specifyed in 5.5.4 Multiple
Connection Handles. Thread safe semantics is provided
Hm. If we are to follow the example in 6.11 this will not work. We would
have to use the SAME session. This means we will have to guard against
concurrent access. We use a stack, and only allowes the handle at the
top of the stack to do things.
As to transactions we some fairly hairy alternatives to handle:
XA - we get an XA. We may now only do transaction through the
XAResource, since a XASession MUST throw exceptions in commit etc. But
since XA support implies LocatTransaction support, we will have to use
the XAResource in the LocalTransaction class.
LocalTx - we get a normal session. The LocalTransaction will then work
against the normal session api.
An invokation of JMS MAY BE DONE in none transacted context. What do we
do then? How much should we leave to the user???
One possible solution is to use transactions any way, but under the hood.
If not LocalTransaction or XA has been aquired by the container, we have
to do the commit in send and publish. (CHECK is the container required
to get a XA every time it uses a managed connection? No its is not, only
at creation!)
Does this mean that a session one time may be used in a transacted env,
and another time in a not transacted.
Maybe we could have this simple rule:
If a user is going to use non trans:
- mark that i ra deployment descr
- Use a JmsProviderAdapter with non XA factorys
- Mark session as non transacted (this defeats the purpose of specifying
- trans attrinbutes in deploy descr NOT GOOD
From the JMS tutorial:
"When you create a session in an enterprise bean, the container ignores
the arguments you specify, because it manages all transactional
properties for enterprise beans."
And further:
"You do not specify a message acknowledgment mode when you create a
message-driven bean that uses container-managed transactions. The
container handles acknowledgment automatically."
On Session or Connection:
From Tutorial:
"A JMS API resource is a JMS API connection or a JMS API session." But in
the J2EE spec only connection is considered a resource.
Not resolved: connectionErrorOccurred: it is verry hard to know from the
exceptions thrown if it is a connection error. Should we register an
ExceptionListener and mark al handles as errounous? And then let them
send the event and throw an exception?
author:
Peter Antman.
author:
Jason Dillon
author:
Adrian Brock
version:
$Revision: 57189 $ | 