The important aspects of using client applications with the RCM and OpenSwitch are:
End-user connectivity
OpenSwitch restrictions
Replication Server restrictions
The most important reason to coordinate your client application with a high availability environment is end-user connectivity. Client applications are typically used by two groups of users—application end users, who write to the back-end database, and decision-support-system (DSS) users, who read the data in the database but never write to it. For the purpose of using the RCM and OpenSwitch, keep these two types of users separate.
To keep these two types of users separate, OpenSwitch requires that you divide them into two pools. Pools are groups of user IDs that log in to OpenSwitch to access the back-end database. Each pool has access to a group of servers that you define in the OpenSwitch configuration file.
The RCM tracks the application end-user pool to detect a login failure but ignores the DSS user pool. OpenSwitch tracks the application end-user pool and the DSS user pool; so if a connection switch is required, it can switch each pool to the appropriate database.
See “Configuring user pools” for more information.
Before configuring the OpenSwitch server, you must:
Identify the users who need continual access to the back-end database.
Divide the group of users into application end-user and DSS-user groups.
Define one or more user pools.
You must define one user pool for application end users. If you have DSS users in your environment, you can define one or more pools through which they can access the system. If you do not need DSS users to access your system, you do not need a DSS user pool.
All application end users must belong to a single user
pool.
Place the user IDs into their corresponding user pools.
See “Configuring OpenSwitch” for more information.
OpenSwitch has several inherent restrictions that can affect your application environment:
Connection context – OpenSwitch does not track and restore current character set, language context, or Adaptive Server context information for a given connection. If the context is changed following the initial connection, the context is lost.
Performance – when you establish a connection through OpenSwitch, the connect time is doubled, because the connection must first be established to the OpenSwitch, which in turn establishes a connection to the remote Adaptive Server.
Also, OpenSwitch must closely monitor all traffic passing between the Adaptive Server and the client connection to detect connection context information. This monitoring activity can have an impact on performance, especially when large result sets are involved.
Number of user connections – because OpenSwitch runs as a single process, the host environment operating system applies constraints on the number of open files per user process.
See the OpenSwitch Administration Guide for more information about OpenSwitch restrictions.
Replication Server does not guarantee the replication of cross-database transactions, which are transactions that modify tables in two or more databases on the same server. Replication Server provides transactional integrity within a single database and across the active and standby databases—but not between two databases on the same server.
See the Replication Server Design Guide for more information.
