[jboss-user] [JCA/JBoss] - Re: Changinh connection state in CMP EJB

dimonv do-not-reply at jboss.com
Tue Jul 21 11:57:37 EDT 2009


Because of the reason you mentioned:
"vickyk" wrote : 
  | Yes putting them in a single pool will cost more when we need to retrieve it back, so efficiency would go down and hence we have sub-pools within the pool, these subpools are created based on Subject/CRI/both(Subject And CRI). 

Assume an RA provides a connection factory:

  | public interface DimiConnection {
  | 
  | }
  | public interface DimiConnectionFactory {
  | 	
  | 	DimiConnection getConnection(String type) throws ResourceException;
  | 
  | }
  | 
and a ConnectionRequestInfo:
public class DimiConnectionRequestInfo implements ConnectionRequestInfo {
  | 	String connectionType;
  | 
  | 	public DimiConnectionRequestInfo(String connectionType) {
  | 		super();
  | 		this.connectionType = connectionType;
  | 	}
  | 	
  | }
the implementation of the connection factory would have a method:

  | public class DimiConnectionFactoryImpl implements DimiConnectionFactory {
  | ...
  | 	public DimiConnection getConnection(String type) throws ResourceException{
  | 			DimiConnectionRequestInfo reqInfo = new DimiConnectionRequestInfo(type); 
  | 			return (DimiConnection)managedConnectionFactory.createManagedConnection(null, reqInfo).getConnection(null, reqInfo);
  | 	}
and its managed connection factory would have a method:

  | public class DimiManagedConnectionFactoryImpl implements ManagedConnectionFactory {
  | ...
  | 	public ManagedConnection createManagedConnection(Subject subject,
  | 			ConnectionRequestInfo cxRequestInfo) throws ResourceException {
  | 	       return new DimiManagedConnectionImpl(this, cxRequestInfo, subject);
  | 	}
  | ...
  | 	public ManagedConnection matchManagedConnections(Set connectionSet,
  | 			Subject subject, ConnectionRequestInfo cxRequestInfo)
  | 			throws ResourceException {
  | 		for(Iterator iterator = connectionSet.iterator(); iterator.hasNext();){
  | 			DimiManagedConnectionImpl dimiManagedConnectionImpl = (DimiManagedConnectionImpl) iterator.next();
  | 			if(dimiManagedConnectionImpl.crinfo.connectionType.equals(((DimiConnectionRequestInfo)cxRequestInfo).connectionType)){
  | 				return dimiManagedConnectionImpl;
  | 			}
  | 		}		
  | 		return null;
  | 	}
  | 

the managed connection implementation has then the method:

  | 	public Object getConnection(Subject subject,
  | 			ConnectionRequestInfo cxRequestInfo) throws ResourceException {
  | 		if(connection == null){
  | 			this.crinfo = (DimiConnectionRequestInfo)cxRequestInfo;
  | 			this.subject = subject;
  | 			try {
  | 				if(crinfo.connectionType.equalsIgnoreCase("A"))
  | 					connection = new DimiConnectionA();
  | 				else
  | 					connection = new DimiConnectionB();
  | 			} catch (Exception e) {
  | 				throw new ResourceException(e);
  | 			}
  | 		}
  | 		return connection;
  | 	}
  | 

As you can see the type of the returned connection depends on CRI. If all managed connections will be put into the single pool could happen that matchManagedConnection() will return null and the server should create a new managed connection.
Therefore in my opinion it makes sense for the PoolByCri with even with re-authentication.


View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4245052#4245052

Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4245052



More information about the jboss-user mailing list