[dimonv]

"vickyk" wrote:
I don't understand this clearly, may be you can explain this with respect to the jdbc rar.

This can not be shown on a JDBC example because JDBC always returns a Connection of the same type. Our JCA connector creates many different connection types, and therefore multiple CRIs result for the same RA. Therefore multiple (sub)pools (one per distinct CRI) should be used. In the patch that you proposed all connections would have been in one pool - wheras we need a PoolByCri. Did I miss something in your Patch that would support a PoolByCri in the re-authentication case?

"vickyk wrote:
Having PoolByCri/PoolBySubject/PoolBySubjectAndCri will basically improve the efficiency/scalable of pooling implementation.

Yes, and by doing this, it must not return connections from the pool with other CRIs then expected by the caller.

"vickyk" wrote:
RA developer should implement the Reauthenication mechanism.

Agreed, this must be implemented in the RA, but be independent of Application Server APIs that are not part of JCA. Your proposed a "reauthenticationClass" which would be AS specific. As pointed out before this is unnecessary in the normal case, and should be implemented by the RA provider (spec 9.1.9) .

[dimonv]

Once more regarding your quote

"vickyk" wrote:
...the reauthentication would be decided at the RA level

If an RA states that it support re-authentication, this does not mean per se that for a specific deployment re-authentication should be used --> this should be a deployment option, defined in -ds.xml. In a use case where the RA is called with few technical users, re-authentication might be too expensive, and a PoolBySubjectAndCri (or PoolBySubject) should be used. In another case with 1000 of end users, the same RA might be used with re-authentication. Since one does not know the internals of an RA, one also does not know how efficient re-authentication is implemented.

"vickyk" wrote:
What I understand is that you wanted to keep the SubPoolCreation even when the re-authentication.

Yes, but only if the deployment (--> ds.xml) requires it (see above).

[vickyk]

"dimonv" wrote:

This can not be shown on a JDBC example because JDBC always returns a Connection of the same type. Our JCA connector creates many different connection types, and therefore multiple CRIs result for the same RA. Therefore multiple (sub)pools (one per distinct CRI) should be used. In the patch that you proposed all connections would have been in one pool - wheras we need a PoolByCri. Did I miss something in your Patch that would support a PoolByCri in the re-authentication case?

No there is no way to create PoolByCri with the patch right now, if re-authentication is enabled.
However I am not able to understand why you need subpools and re authentication, both of them should be mutually exclusive.

[dimonv]

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.

[dimonv]

Hi,
Is anybody there? Is it now clear?

No there is no way to create PoolByCri with the patch right now, if re-authentication is enabled.

What do you mean "re-authentication is enabled"? How is it configured?

[vickyk]

Jesper,

This one had been there for long time so wanted to close it now

I am planing to put a fix here

http://anonsvn.jboss.org/repos/jbossas/branches/Branch_4_2/

Any thoughts about it?

[jesper.pedersen]

My early comment about better error checking still applies - e.g. what if changeUser is null f.ex.

Also features should go on AS/trunk - not on an old branch.