1 2 Previous Next 21 Replies Latest reply on Mar 8, 2010 2:49 PM by jesper.pedersen

    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

        • 1. Re: Changinh connection state in CMP EJB

          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.

          • 2. Re: Changinh connection state in CMP EJB
            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.

            • 3. Re: Changinh connection state in CMP EJB
              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

              • 4. Re: Changinh connection state in CMP EJB

                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.

                • 5. Re: Changinh connection state in CMP EJB
                  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?

                  • 6. Re: Changinh connection state in CMP EJB

                     

                    "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).

                    • 7. Re: Changinh connection state in CMP EJB
                      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.



                      • 8. Re: Changinh connection state in CMP EJB
                        vickyk

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

                        • 9. Re: Changinh connection state in CMP EJB
                          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

                          • 10. Re: Changinh connection state in CMP EJB
                            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);
                             }
                             }


                            • 11. Re: Changinh connection state in CMP EJB
                              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

                              • 12. Re: Changinh connection state in CMP EJB
                                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.


                                • 13. Re: Changinh connection state in CMP EJB
                                  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.

                                  • 14. Re: Changinh connection state in CMP EJB
                                    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.


                                    1 2 Previous Next