[ https://issues.jboss.org/browse/TEIID-4183?page=com.atlassian.jira.plugin... ] Ramesh Reddy commented on TEIID-4183: ------------------------------------- [1] As far as "passthough login module" is concerned, it does not force the JCA layer to make a new connection, however it does negotiates/creates a subject (which may involve conversation with the kerberos domain server) that be little slow. Now, if SQL server JDBC driver does not have a way to re-purpose the existing connection, and re-authenticate the new user, then it may be creating a new connection, there we have NO control over that behavior. But, looks like your suggestion of adding security-domain cache is preferred/recommended. I will add to the documentation. [2] For this to go away you need add "<prefill>false</prefill>" to configuration of the data source. This flag MUST be false in every situation where pass-through is used, not specific to kerberos. if <prefill> is true, even with previous version you probably would have seen {code} 09:37:47,325 WARN [org.jboss.jca.core.connectionmanager.pool.strategy.PoolBySubject] (JCA PoolFiller) IJ000610: Unable to fill pool: javax.resource.ResourceException: No matching credentials in Subject! at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:965) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:233) at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.createConnectionEventListener(SemaphoreArrayListManagedConnectionPool.java:858) [ironjacamar-core-impl-1.0.37.Final-redhat-1.jar:1.0.37.Final-redhat-1] at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.fillToMin(SemaphoreArrayListManagedConnectionPool.java:801) [ironjacamar-core-impl-1.0.37.Final-redhat-1.jar:1.0.37.Final-redhat-1] at org.jboss.jca.core.connectionmanager.pool.mcp.PoolFiller.run(PoolFiller.java:97) [ironjacamar-core-impl-1.0.37.Final-redhat-1.jar:1.0.37.Final-redhat-1] at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_77] {code} The above is WARN, not an error. But with <prefill> omitted, I did not see any exception, which leaves to believe prefill default and its effects are some where in between. But, I did find a error case during the startup, I fixed that in the code. You mean this using the connection second time? if yes true that is behavior we expect. Even though we are pass through, it should behave as if original ticket has been invalidated, just like in static case. I expect this. BTW, this is specific to SQLServer again. yes, this is expected, as this is reason we were doing wrapping for sql server. We both are saying same thing :) - when cache is used * Yes, as long as you use the security domain's cache, you will see the same as previous behavior. * When cache is used the logout method is overridden in cache (i believe) and cache keeps the subject intact to be used on future calls. * When cache is flushed then you will see subjects gone, then calls go back through pass-through mechanism again, until then this code will not be hit, it will use the subject from the cache. - When cache not used * The ticket is *never* invalidated by the pass-though module, unlike top level kerberos login module, but subject's is stripped out of its ticket credential (in sql server case invalidation at driver) * Removing of any other credentials from subject is equally will be true for any other credentials like OAuth, user/passwd scenarios too. This will occur when logout is called. This is something, I missed before where I was not cleaning the subject on logout, I do suspect this should NOT affect any of the current test scripts IMO, but if you are seeing any variance please let me know, we will figure out the issue. -- This message was sent by Atlassian JIRA (v6.4.11#64026)