Changinh connection state in CMP EJB

[lmouillart]

Hi, I use JBoss 3.2.x on Windows but connected on iSeries DB2 datasource. On our DB2 there are lots of tables proposed to the user, but it depends with wich profile the user is connected. I have writtent a SQL procedure that change the iSeries user context. In current state this procedure must be called on all getConnection().

So, I would like call this procedure from a CMP EJB to change the state of the connection and resend theme to the CMP EJB so that it can save it's state with the good connection context.

I prospect to user <check-valid-connection-sql> sql code </check-valid-connection-sql>
or
<valid-connection-checker-class-name>validconnectionchecker</valid-connection-checker-class-name>
But i don't know, how to use it.

Is it possible, to call this procedure and send them parameters (and how) ?

Thank's

[adrian.brock]

What you are after is called in the spec reauthentication-support.

The jboss jdbc resource adapter currently does not support it, but I would be interested
if you want to provide a patch. i.e. in getConnection() and matchManagedConnections()
it should callout to a user defined piece of java code passing the ManagedConnection,
ConnectionRequestInfo and Subject so you it can work with it.

It also requires a small tweak to the matching algorithm, since it no longer needs to
fail requests from different users if it is going to change the user. Probably
by delegating the check to you?

You would configure it your -ds.xml

<reauthentication>com.acme.Reauthenticate</reauthentication

Without this change, you need to create separate subpools for each user.

<application-managed-security/>

The valid connection checker only runs when a connection is being reused, not
when a connection is first created.

[lmouillart]

Thank's but finally I think that using, one datasource by user (a firm) and one jboss instance by firm is a best choice, and remove the overhead of the context swtiching.

[ricardoarguello]

Adrian:

I would be interested in developing this JCA re-authentication support, and also an specific plug-in for the Oracle DB. Since this thread is from 2004, do your instructions for developing this feature are still correct against the current release (4.0.5)?

Related Issue:
http://jira.jboss.com/jira/browse/JBAS-1429

[adrian.brock]

Yes, the instructions are still the same (if a little scant of details :-).

It's basically:
1) A configuration option in BaseWrapperManagedConnectionFactory
to define the reauthentication mechanism class

2) Define an interface in org.jboss.resource.adapter.jdbc.vendor for the reauthentication
mechanism, e.g. something like:

public interface ReauthenticationMechansim
{
 void reauthenticate(Connection c, String user, String password) throws SQLException;
}

3) Invocation of the reauthentication during matchManagedConnections()
and suppression of any failure to match of the CRI/Subject.

4) An option on the JBossManagedConnectionPool to tell it to reduce the pooling
to one-pool since multiple pools (for different users/passwords - subjects) are no longer required.

5) Change the xslt to have a

<reauthentication-mechanism>some.class.name</>

for data-sources that does the configuration for both (1) and (4)

Actually (4) is probably a bit more complicated for generic pooling where
the CRI (connection request info) can have other parameters besides
user/password. e.g. the JMS rar has queue/topic connection,
but making it work for the JDBC adapter will be a good start.

And (3) needs some care to make sure errors thrown by the reauthenication
mechanism are handled properly, i.e. don't match the conneciton so it is then
destroyed as broken.

[vickyk]

Adrian,

Considering the following scenario

Assuming that in MySQL Database we have a Reauth-Schema SCHEMA with the following tables:
1) Table0
2) Table1
3) Table2

Considering there are 3 users with the following username/password

1) user1/password1
2) user2/password2
3) user3/password3

Now user1,user2 and user3 can access Table0
user2 can only access Table1
user3 can only access Table2

I think I can use GRANT feature in MySql I have yet not tried this ?..

Considering the following flow in the application code
1) Create a connection Pool for user1/password1.
2) Get the connection from the pool which is created in the Step1.
3) Fire a DML command on the Table0.
4) Now, try to fire the command on the Table1.

The Step4 should now get executed as Table1 can't be accessed by user1 identity. The work around should be to change the identity associated with the connection when taken from the Connection Pool for the Step 4.

This is what I understand from the Re-Authentication feature from the EIS(MySql side) , however I am not sure of how to make such settings.

I am trying to understand the Reauthentication feature at EIS side, is this how it works?

[adrian.brock]

"vickyk" wrote:
Adrian,

Considering the following scenario

Reauthentication has nothing to do with SQL GRANT (authorization).
It is simply about changing the user under which the connection runs.
Anything else is is database configuration (authority not authentication).

[vickyk]

The required changes are attached here
https://jira.jboss.org/jira/browse/JBAS-1429
The reauthenitication mechanism with jdbc ra will work when
1) <reauthentication-support> tag is enabled in ra.xml at jboss-local-jdbc.rar/META-INF/ra.xml AND jboss-xa-jdbc.rar/META-INF/ra.xml
AND
2) The -ds.xml corresponding to the local-tx-datasource AND xa-datasource would have <reauthentication-mechanism> pointing to the appropriate reauthentication mechanism implementation.

Missing of any of the configuration would cause *misbehavior* of the JCA pooling mechanism.
We should have a way to pass the reatuthentication details to the MCF e.g
mcf.setReauthenticationTrue(true);
Should we not have reauthentication related API as a part of the MCF ?

For other RA's to support re-authentication what they need is
1) Enable the <reauthentication-support> in the vendor-specificRA.rar/META-INF/ra.xml

AND

2) provide connection-property for CF which will tell the MCF to use the reauthentication.

[vickyk]

Adrian,
Any review comments on the changes I have attached to the related JIRA?

[jesper.pedersen]

Vicky, I looked over our patch - if you could update it in the area where error conditions happens - f.ex. F.ex. if the user has specified an incorrect class name, the driver hasn't been deployed to the lib/ directory, if the method doesn't exist on the class and so on.

Lets focus on getting the JDBC RA updated first, then we will look at the MCF /CF cases.

Thanks

[vickyk]

Jesper,I am not sure which additional checks you are asking for,these checks are already there
1)

"jesper.pedersen" wrote:
if the user has specified an incorrect class name, the driver hasn't been deployed to the lib/ directory,

BaseWrapperManagedConnectionFactory::loadReauthClass()

catch (Exception e)
 {
 throw new JBossResourceException("Failed to load the reauthentication class " + reauthenticateClassName, e);
 }
 }

2)

"jesper.pedersen" wrote:

if the method doesn't exist on the class and so on.

It is tackled in the vendor implementation of the ReauthenticationMechansim e.g

MySqlReauthenticationMechansimImpl::reauthenticate

catch (Exception e)
 {
 Throwable t = e.getCause();
 if (t instanceof SQLException) {
 throw (SQLException)e;
 } else {
 log.error("Unexpected error in changeUser", e);
 }
 }

[dimonv]

I'm interesting on re-authentication as well, but my case relates to a non-JDBC RA (http://www.jboss.org/index.html?module=bb&op=viewtopic&t=155124).

Nevertheless I had a look into the patch suggested by Vicky and have some comments regarding org.jboss.resource.connectionmanager.JBossManagedConnectionPool. Even if an RA supports re-authentication, its connections may not be put into a OnePool per default, since their CRIs e.g. types can differ.

Moreover if an RA supports re-authentication, it doesn't mean automatically that re-authentication should be applied, I think it's the matter of -ds.xml. The criteria like "ByContainerAndApplication", "ByContainer", which require authentication, do not express any requirements for re-authentication. Probably an addition tag within -ds.xml combined with "ByContainer..." is needed to give org.jboss.resource.connectionmanager.JBossManagedConnectionPool a hint which pool implementation should be used.

Thanks and kind regards,
Dmitri

[vickyk]

"dimonv" wrote:

Nevertheless I had a look into the patch suggested by Vicky and have some comments regarding org.jboss.resource.connectionmanager.JBossManagedConnectionPool. Even if an RA supports re-authentication, its connections may not be put into a OnePool per default, since their CRIs e.g. types can differ.

What issue do you see here?

"dimonv" wrote:

Moreover if an RA supports re-authentication, it doesn't mean automatically that re-authentication should be applied, I think it's the matter of -ds.xml.

Not really IMO, the reauthentication would be decided at the RA level. The -ds.xml should then supply the infrastructure needed to support the reauthentication i.e reauthentication mechanish as in case of jdbc rar.
Logically re-authentication means a single pool.

[dimonv]

"vickyk" wrote:
What issue do you see here?

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. 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.
BTW I thought that was one of the reasons for org.jboss.resource.connectionmanager.JBossManagedConnectionPool.PoolByCri implementation.
If you say:

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

why do you need any additional infrastructure for the re-authentication?

"vickyk" wrote:
The -ds.xml should then supply the infrastructure needed to support the reauthentication i.e reauthentication mechanish as in case of jdbc rar.

And if we use a JCA-compliant RA supporting re-authentication, who is responsible for supplying a re-authentication mechanism?
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.
IMO the only what -ds.xml needs is:

"dimonv" wrote:
Probably an addition tag within -ds.xml combined with "ByContainer..." is needed to give org.jboss.resource.connectionmanager.JBossManagedConnectionPool a hint which pool implementation should be used.

Thus if -ds.xml says e.g. true and <security-domain-and-application>sec domain</security-domain-and-application> or <security-domain>sec domain</security-domain> then PoolBySubjectAndCri resp. PoolBySubject should be used.

[vickyk]

"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

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.

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.

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.