Concurrent Administration and Reflection for the Web or Reflection Security Gateway

This technical note describes the concurrent administration feature available in Reflection for the Web and Reflection Security Gateway on a standalone server and in a replication environment.

Concurrent Administration

Concurrent administration can be used with a standalone Reflection for the Web server and with multiple replicated servers.

Before the concurrent administration feature was added to Reflection for the Web, only one administrator could work in the Administrative WebStation at a time. The first administrator would get a lock on the Administrative WebStation, and no other administrator could make changes in any part of the Administrative WebStation while the first administrator held the lock.

The concurrent administration feature allows multiple administrators to access the Administrative WebStation, as long as they are not configuring the same settings at the same time. The various parts of the Administrative WebStation are divided into units of administration. For example, in the Settings tool, each tab is a separate unit. One administrator can be in one tab, and another administrator can be in another tab, but two administrators cannot be in the same tab at the same time.

In general, each tab is a separate unit. The access control wizard is a single unit. In the Session Manager, each individual session is a separate unit. (In other words, two administrators can be in the Session Manager at the same time and can edit different sessions at the same time, but they cannot edit the same session concurrently.) Multiple administrators can use the Access Mapper at the same time, but only one administrator at a time can map sessions to a particular LDAP user or LDAP group.

When an administrator enters a particular part of the Administrative WebStation, (for example, a tab on the Settings tool) the administrator locks that tab. The lock is released when the administrator moves away from that tab.

Configuring the Concurrency Lock Timeout

The default concurrency lock timeout period is three minutes. If it takes you longer than three minutes to complete your settings, and your lock expires, you can still save your settings as long as no other administrator changed the same settings while you were working. You can configure the timeout in Settings > Replication; the minimum timeout is one minute.

Concurrent Administration and Replication

The concurrent administration feature also works in a replication environment. Multiple administrators can be working in different parts of the Administrative WebStation at the same time, and those administrators can be connected to the master or any slave server.

In a replication environment, all the locks are controlled by the master server. If you are connected to the Administrative WebStation on a slave server, and you open (for example) a particular tab on the Settings tool, the slave requests a lock from the master server for that tab.

If the master server is not available, then the slave server cannot get a lock, and you are unable to change any settings on the slave server. The one exception is the Replication tab – you can always get to the Replication tab on a slave server. This tab enables you to control the slave server and change it to a standalone or master server while the unavailable master is down.

Replication is intended to provide failover and redundancy for end-user access, by keeping the configuration status of multiple Reflection for the Web servers synchronized so that the servers can function behind a load balancer. If any of the slave servers go down, or if the master server goes down, end users are still able to connect to another server (whether slave or master) and get full access to their sessions.

Note that the replication feature is not intended to provide full failover and redundancy for administrator access to the Administrative WebStation. If one of the slave servers goes down, then administrators are still able to access the Administrative WebStation through another slave server or through the master. However, if the master goes down, then administrators are unable to change any settings on the slave servers until the master is restored or a new master is configured, because without the master, the slaves can’t get locks. (As stated above, the one exception is the Replication tab on the slave servers, which is always available even if the master is down.)

For detailed information about configuring replication in Reflection for the Web or Reflection Security Gateway, see KB 7021590.

For information about what to do if your master server goes down, see KB 7021591.

Legacy KB ID

This article was originally published as Attachmate Technical Note 2371.