"dimonv" wrote : | There are cases in which the same RA provides connections of the different types. If the client application calls an additional getConnection method of the RA and provides the meta-info to it, which contains e.g. the java type of connection, and then casts the returned connection to the type it has requested ClassCastException occurs. | I don't understand this clearly, may be you can explain this with respect to the jdbc rar. "dimonv" wrote : | Another example is JBoss' JMS RA; it provides a class called org.jboss.resource.adapter.jms.JmsConnectionRequestInfo which implements of javax.resource.spi.ConnectionRequestInfo. org.jboss.resource.adapter.jms.JmsConnectionRequestInfo defines the type of connection returned by RA: topic, queue or both, I assume all of these types can not be put into the same pool. | 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). "dimonv" wrote : | BTW I thought that was one of the reasons for org.jboss.resource.connectionmanager.JBossManagedConnectionPool.PoolByCri implementation. | The reason is the efficient management of the pool as per my understanding. The JCA specs does not specify how an application server should implement Connection Pool, it is left to the AS vendor. The suggested approach in the specs is explained in sec6.5.3.3 reads this anonymous wrote : The per-ManagedConnectionFactory instance pool may be further partitioned | based on the transaction or security context or any client-specific parameters (as | associated with the ConnectionRequestInfo). When an application server calls the | matching facility, it is recommended that the application server narrow down the | candidate set of ManagedConnection instances to a reasonable limit, and achieves | matching efficiently. For example, an application server may pass only those | Having PoolByCri/PoolBySubject/PoolBySubjectAndCri will basically improve the efficiency/scalable of pooling implementation. Imagine you have thousands of connection and if these are classified in groups based on Subject/Cri then the searching the connection could be improved. "dimonv" wrote : | why do you need any additional infrastructure for the re-authentication? | To provide more flexibility as you can see from the patch where you can plug in the custom re-authentication mechanism via -ds.xml. anonymous wrote : | And if we use a JCA-compliant RA supporting re-authentication, who is responsible for supplying a re-authentication mechanism? | RA developer should implement the Reauthenication mechanism. anonymous wrote : | Even in case of JDBC no additional mechanism is not necessary in -ds.xml; this mechanism should be behind getConnection, as described in chap. 9.1.9 of JCA specification. | Is it not behind the getConnection()? It is the getConnection() call on the MCF which invokes the ConnectionManager which in turn talks to the ConnectionPoolImplementation for getting the connection. What I understand is that you wanted to keep the SubPoolCreation even when the re-authentication. The purpose of reauthentication is to avoid the searching of valid connection in a pool as it would improve the performance when pool size is too large. View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4244895#... Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&a...