API calling sequence - Connection concentrator

This scenario covers the API calling sequence when connection concentrator is used. The connection concentrator feature allows the database manager to handle many more clients than there are coordinating agents or threads. This API calling sequence applies to communication buffer exit libraries.

When a client reaches a unit of work boundary and does not send another request immediately, client sockets are placed into an idle pool. The agent that previously handled client requests moves on to another client. When the idle socket has data to read, a dispatcher finds an idle agent to handle it. Over the life of an SQL connection, there might be multiple agents that handle the client requests. Each time the socket is moved in and out of the idle pool, db2commexitDeregister and db2commexitRegister are called. The following calls are made:
  1. db2commexitRegister for a new socket connection.
  2. db2commexitRecv and db2commexitSend to handle authentication, possibly multiple times.
  3. db2commexitUserIdentity for a new connection
  4. db2commexitRecv and db2commexitSend to handle client SQL requests, possibly multiple times.

    The client does not send another request immediately and the socket is placed into an idle pool.

  5. db2commexitDeregister to disassociate with the agent.

    At some future point, the client sends another request, at which point the dispatcher chooses an idle agent. The agent is likely a different one than used previously:

  6. db2commexitRegister to associate an agent.
  7. db2commexitRecv and db2commexitSend to handle client SQL requests, possibly multiple times.
  8. db2commexitDeregister to terminate socket connection.
Note: There are multiple calls to db2commexitRegister and db2commexitDeregister for a single SQL connection.