Results 1 to 7 of 7
  1. #1
    Join Date
    Jan 2007
    Posts
    33

    Unanswered: What is the logic behind the federated server?

    hi,

    In db2, we are creating the federated object to access from another db2 database. To do that we are creating wrapper, server, usermaping and nicknames.

    to create a server...

    CREATE SERVER <SERVERNAME> TYPE DB2/UDB VERSION 8.1 WRAPPER <WRAPPERNAME> AUTHORIZATION "MYID" PASSWORD "MYPASSWD" OPTIONS ( DBNAME 'SAMPLE');

    as per ibm documentation, the authorization id and password used to bind the packages and it establish connection to the db2 server while creating server.

    now i have some queries

    1. where is the authorization id and password information stored?

    2. If i change the remote db instance password, still i am able to access the federated object. whenever i am accessing the federated object, will it use the authorization id and password? or Not?

    can any dba person explain this.

    thanks in advance

    Sanjai
    Last edited by sanjai; 06-03-08 at 10:43.

  2. #2
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    For the CREATE SERVER command, the username password are not stored anywhere. They are only used for the duration of the CREATE SERVER command. If you change a password on the source server you would use ALTER USER MAPPING to change the password on the federation server.

    Andy

  3. #3
    Join Date
    Jan 2007
    Posts
    33
    thanks for your reply Andy.

    For user mapping we can change the password thru alter user mapping command. that is working fine.

    here,

    for example,

    i am using the (remote) db2 database instance ownerid and password as authorization id and password to create a server. When it is creating the server, it will use the authorization id and password to connect to the db.

    after creating the server, user mapping and nickname, i was able to see the records from the remote db.

    then i have changed the password for the remote instance. Now also i am able to access those nicknames.

    I would like to know that what kind of action/logic is used by db2 whenever we access the nickname?
    Because we have changed remote instance password also. will the db2 uses the authorization id and password each time we connect to remote db to access the nickname?

    kindly explain

    Sanjai

  4. #4
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    Let me try to explain it this way. Server A has all of the federation setup to access server B table xxx with a nickname of nick_xxx. A user connect to server A and does normal processing. The first time the use reference nick_xxx, a connection to Server B from Server A will be established using the current authentication setup on server A (User mapping). For the entire time the user is connected to server A, the connection to server B on his behalf from server A will stay in effect. So any subsequent references to nick_xxx will use the same connection. When the user disconnects from server A, the connection to server B will also terminate.

    When you change a password on server B, any new connections from server A will fail until you use ALTER USER MAPPING to remedy the situation. Any current connections from server A will stay in effect and not need reauthorization.

    Does that make things clearer?

    Andy

  5. #5
    Join Date
    Jan 2007
    Posts
    33
    thanks Andy. I got a clear picture on user mapping.

    what about authorization id and password? what is the use of it?

    Will it check each time we access the federated table? or Only at the time of federated server creation?

    Thanks

    sanjai

  6. #6
    Join Date
    Jan 2003
    Posts
    4,292
    Provided Answers: 5
    The source server (server B in my example) is just a DB2 database, and just like every other DB2 DB, it requires authentication to allow access. When the CREATE SERVER command is issued on the federation server (server A), it needs to access the source server. That is why you need a username-password on the command. It is only valid for THE DURATION OF THE COMMAND and is no longer needed when the command is completed, so the username-password is not persisted anywhere.

    As I explained earlier, authentication during table access is not done each time the table is accessed. The federating server (server A) will hold a connection open for each user/application that is accessing the federated table. This connection is just like any other connection to a database (especially as far as server B is concerned). It is just made transparently to the users accessing the federated table through server A.

    Andy

  7. #7
    Join Date
    Jan 2007
    Posts
    33
    thanks Andy

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •