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.
For user mapping we can change the password thru alter user mapping command. that is working fine.
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?
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.
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.