Collisions in login management

When two actions with conflicting results execute at about the same on two servers in a multiplex, a collision occurs. To resolve collisions, one action takes effect and overwrites the other. Propagation of settings among the servers in the multiplex will result in the settings that match on all servers.

For example, suppose that a DBA on one server sets the default connection limit for new users to 10 and another DBA sets it to 15. Once propagation completes, the result is that either all servers see the setting as 10, or else all servers see it as 15.

Ideally, the change that was done last should persist, but in this situation, it is not critical for any of the login management features. Because SQL Remote propagates the changes, one of the changes fails and the earlier update persists.

WARNING! Due to a known issue with SQL Remote, Sybase recommends that you avoid performing batches of login management operations simultaneously on multiple servers without synchronizing afterwards.

When a row or column is updated on a remote server twice within a minute, at the same time that the same row/column is updated on the consolidated server, the remote server stores the first value specified instead of the second value. The second update is not propagated from the SQL Remote update of the second value on the consolidated server. If this state occurs, synchronizing query servers or changing the value on any server corrects it.

Sybase recommends that, whenever possible, you perform login management changes on the write server. If necessary, you can make changes on any query server, but avoid making conflicting changes on another server until all query servers have been synchronized by SQL Remote.

For information about static collisions involving permissions, see “Setting multiplex permissions”.