![[SERVER]](arrow-left.gif){kind=icon}
![[LIMIT_RESOURCE]](arrow-right.gif){kind=icon}
Complete this section once for each Adaptive Server pool you want defined within OpenSwitch. The section includes the pool name, any attributes of the pool, the set of servers contained within the pool, and the set of connections that the pool serves.
[POOL=POOL_NAME[: OPTION=VALUE[, OPTION=VALUE ]]] [servers:] SERVER_NAME [SERVER_NAME ...] [connections: attribute: regex [, regex] [attribute: regex [, regex] ...]]
POOL_NAME – a unique pool name up to 30 characters in length.
OPTION and VALUE – a
configuration option specific to POOL. Table 5-3 shows valid input
for these parameters, which are entered in the format OPTION = VALUE.
OPTION |
VALUE |
|---|---|
MODE |
The operational mode of the pool:
|
STATUS |
The status of the pool:
Pools can also have a PRE_UP, PRE_DOWN, PRE_LOCKED, or SUSPENDED status. These states are specific to pools in a mutually-aware implementation. Never manually set a pool’s status to these states. For more information, see “Pool states”. |
CACHE |
The number of seconds that connections are cached following a user disconnect. See “Using connection caching”. The value is an integer in seconds. |
[servers: server_name=status server_name=status]
“servers” is an optional [POOL] subsection that lists the servers in the pool, and optionally the server’s status.
server_name – the remote server defined in the $SYBASE/interfaces file on UNIX and %SYBASE%\ini\sql.ini on Windows.
During OpenSwitch start-up, no validation is done to
verify whether or not these servers exists.
status – (optional) enter the status of the server you specified with server_name at the pool level. When you specify the server status in the [SERVER] section of the configuration file, the status is applied globally. When you supply a status here, the value overwrites the server’s global status with the status you enter for this server in this pool. This allows the same server to have a different status in different pools, allowing you to failover selected applications to back-up servers. Enter:
UP – the server is currently available.
DOWN – the server is unavailable, and will not be considered for use by any new client connections established to the OpenSwitch.
LOCKED – the server is available, but any new incoming connections or existing connections switching to the server are blocked (or stopped) until the status is changed to UP or DOWN. Blocked connections appear to client applications to have stopped responding until the server is unlocked.
Servers can also have a PRE_UP, PRE_DOWN, or PRE_LOCKED status; however, you should never manually set a server’s status to these states. For more information, see “Server state”.
You cannot start OpenSwitch with a server in the LOCKED state.
To start OpenSwitch, all servers must be either UP or DOWN. Once
OpenSwitch starts, use rp_server_status to
change the server STATUS to LOCKED.
For more information, see “Server state”.
[connections: attribute: regex [, regex] [attribute: regex [, regex] ...]]
Optional [POOL] subsection that lists the attributes that define a set of connections that use this pool.
attribute – the name of a connection attribute. Valid attributes are:
Attribute |
Description |
|---|---|
username |
Match the user name supplied by the Open Client connection. |
appname |
Match the application name declared by the Open Client connection. |
hostname |
Match the host name on which the Open Client connection is running. |
type |
Match the type of incoming connection as either a site connection or a client connection. Possible values are:
|
regex – the value for the specified attribute. This can also be a standard SQL-style extended regular expression that describes values for a given attribute that uses this pool. You can use wildcard expressions to specify a range or group of acceptable attribute values.
If you omit the [connections] subsection of the pool configuration, all connections are a match for the pool. However, the order in which pools are defined is important; a connection is routed to the first matching pool. Therefore, Sybase suggests that you keep a “catch-all” pool without a [connections] section at the end of the pool list.
In this example, any client that logs in to OpenSwitch with the user name of “john” or the application name “isql” (depending on the USE_AND_TO_POOL_ATTRIB setting) is first channeled to the Adaptive Server ASESRV1, which has a status of UP in POOL1.
If the client fails to connect to ASESRV1, or it has been marked as DOWN explicitly by the coordination module or the administrator, the clients are channeled to ASESRV3 because ASESRV2 is marked as DOWN in POOL1.
When a client disconnects, its connection to the Adaptive Server is cached for as long as five minutes. If the same user with the same password reconnects within that period, he or she can reuse the cached connection, thereby saving the overhead of creating a new outgoing connection.
In this example, “john” is the regex value for the “username” attribute, and “isql” is the regex value for the “application” attribute:
[POOL=POOL1:MODE=CHAINED,CACHE=300] servers: ASESRV1=UP ASESRV2=DOWN ASESRV3=UP connections: username: john appname: isql
