Save This Page
Home » jboss-5.0.0.CR1-src » org.jboss.resource.adapter » jms » [javadoc | source]
org.jboss.resource.adapter.jms
public class: JmsManagedConnection [javadoc | source]
java.lang.Object
   org.jboss.resource.adapter.jms.JmsManagedConnection

All Implemented Interfaces:
    javax.jms.ExceptionListener, javax.resource.spi.ManagedConnection

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:

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?

Constructor:
 public JmsManagedConnection(JmsManagedConnectionFactory mcf,
    ConnectionRequestInfo info,
    String user,
    String pwd) throws ResourceException 
    Create a JmsManagedConnection.
    Parameters:
    mcf -
    info -
    user -
    pwd -
    Throws:
    ResourceException -
Method from org.jboss.resource.adapter.jms.JmsManagedConnection Summary:
addConnectionEventListener,   associateConnection,   cleanup,   destroy,   getConnection,   getInfo,   getLocalTransaction,   getLogWriter,   getManagedConnectionFactory,   getMetaData,   getSession,   getUserName,   getXAResource,   lock,   onException,   removeConnectionEventListener,   removeHandle,   sendEvent,   setLogWriter,   start,   stop,   tryLock,   unlock
Methods from java.lang.Object:
equals,   getClass,   hashCode,   notify,   notifyAll,   toString,   wait,   wait,   wait
Method from org.jboss.resource.adapter.jms.JmsManagedConnection Detail:
 public  void addConnectionEventListener(ConnectionEventListener l) 
    Add a connection event listener.
 public  void associateConnection(Object obj) throws ResourceException 
    Move a handler from one mc to this one.
 public  void cleanup() throws ResourceException 
    Cleans up the, from the spec - The cleanup of ManagedConnection instance resets its client specific state. Does that mean that autentication should be redone. FIXME
 public  void destroy() throws ResourceException 
    Destroy the physical connection.
 public Object getConnection(Subject subject,
    ConnectionRequestInfo info) throws ResourceException 
    Get the physical connection handler.

    This bummer will be called in two situations:

    1. When a new mc has bean created and a connection is needed
    2. When an mc has been fetched from the pool (returned in match*)

    It may also be called multiple time without a cleanup, to support connection sharing.

 protected ConnectionRequestInfo getInfo() 
    Get the request info for this connection.
 public LocalTransaction getLocalTransaction() throws ResourceException 
    Get the location transaction for the connection.
 public PrintWriter getLogWriter() throws ResourceException 
    Get the log writer for this connection.
 protected JmsManagedConnectionFactory getManagedConnectionFactory() 
    Get the connection factory for this connection.
 public ManagedConnectionMetaData getMetaData() throws ResourceException 
    Get the meta data for the connection.
 protected Session getSession() 
    Get the session for this connection.
 protected String getUserName() 
    Get the user name for this connection.
 public XAResource getXAResource() throws ResourceException 
    Get the XAResource for the connection.
 protected  void lock() 
 public  void onException(JMSException exception) 
 public  void removeConnectionEventListener(ConnectionEventListener l) 
    Remove a connection event listener.
 protected  void removeHandle(JmsSession handle) 
    Remove a handle from the handle map.
 protected  void sendEvent(ConnectionEvent event) 
    Send an event.
 public  void setLogWriter(PrintWriter out) throws ResourceException 
    Set the log writer for this connection.
  void start() throws JMSException 
  void stop() throws JMSException 
 protected  void tryLock() throws JMSException 
 protected  void unlock()