This document describes the technical background of the replication methodology in the CA Single Sign On server farm system.
Moreover it highlights the Transaction Manager component utilized by Policy Manager and is discussing an issue arising when working with the Policy Manager alternatively on the various farm member systems.
Error as displayed in the Policy Manager
While deleting or modifying objects in the Policy Manager it may happen that an error ?Failed to fetch data? is returned. This is only occurring for Application and/or any other SEOSDB (Access Control) objects and is relating to the Transaction Manager component.
A sample of this error is shown below:
Technical Background information
This kind of error is caused due to the specific replication methodology used by CA Single Sign On server farm to synchronize the members' SEOSDB.
To demonstrate this problem we suppose to have a Policy Server farm consisting of two members as shown in this schematic design:
The PM/TM components are running on the administrative workstation.
SEOSDB/PMDB run on each member of this SSO server farm.
Reason for the error in the Transaction Manager (TM) is the following:
- A Policy Manager (PM) initiated transaction, made on first server, forwards the activity done to objects in the Access Control (AC) database (seosdb) where the PM is connected to AND to the TM which is running on the same administrative workstation.
- The TM is forwarding this transaction to the local PMDB (ps_pmdb).
- TM is writing the transaction into the ps_pmdb database, as well as to this ps_pmdb 's update file (update.dat)
- Changes in the update.dat will be replicated unconditionally to each seosdb subscriber on the other members of the server farm.
- The changes are NOT replicated to ps-pmdb of the second member of server farm.
Hence, the error shown above is caused when TM is attempting to update or delete objects not existing in the one ps_pmdb.
In case the administrator is connecting with the PM/TM not always to the same member system, the ps_pmdbs go out of sync gradually, since transactions are only written to the one ps_pmdb but not to the other ps_pmdbs.
However, these errors can be safely ignored, since the ps_pmdb DB is actually not utilized in SSO. What is relevant is that the transaction is correctly passed to the update file and transferred to the subscriber.
To avoid this condition, it is recommended to always connect with the PM to the very same farm member in order to perform any administrative changes.
Useful commands (to retrieve troubleshooting information):
To verify the contents of the update file, please use the following command:
sepmd -C PS_PMDB
To print a list of subscribers for the Policy Model and their status:
sepmd -L PS_PMDB
Please note that the update.dat file is not cleared automatically.
It is recommended to clear the update.dat file from time to time for maintenance reasons.
To truncate the updates file:
sepmd -t PS_PMDB auto