Open topic with navigation
It is possible for an OmniGroupServer repository to be updated and queried at the same time. However, in theory this could cause the results of queries to be incorrect. This is because OmniGroupServer could be part way through processing a new user or group as the query is processed.
OmniGroupServer can redirect queries from one repository to another. You can use this feature to prevent OmniGroupServer simultaneously updating and querying a repository. This section explains how to configure redirection.
An easier approach than setting up redirection is to configure one task to crawl a repository for updates, and then copy the information into another OmniGroupServer repository that can receive queries from IDOL. You can do this using
GroupServerJobType=combine, for example:
[Repositories] 0=RepositoryThatGetsUpdates 1=RepositoryThatIsQueried [RepositoryThatGetsUpdates] // Task settings [RepositoryThatIsQueried] GroupServerJobType=combine GroupServerSections=RepositoryThatGetsUpdates GroupServerStartDelaySecs=10
To set up redirection, you must set up multiple OmniGroupServer repositories to retrieve user and group information from the same source. One of these repositories can be queried while the others are updated.
You can use redirection with any type of repository, however it is most useful in cases where OmniGroupServer takes a significant amount of time to update a repository.
The following example configuration shows how to configure redirection. Queries are directed to
[Default] GroupServerLibrary=ogs_example.dll GroupServerCycles=-1 GroupServerRepeatSecs=86400 GroupServerSkipIfCanQuery=TRUE GroupServerClearDatastoreOnStart=TRUE GroupServerRedirectOnCompletion=MainRepository [Repositories] GroupServerDefaultRepositories=MainRepository Number=2 0=MainRepository 1=SecondaryRepository [MainRepository] GroupServerStartTime=06:00 GroupServerRedirectedQueriesOnly=FALSE [SecondaryRepository] GroupServerStartTime=18:00 GroupServerRedirectedQueriesOnly=TRUE
The following steps explain how this configuration works:
SecondaryRepositoryare empty. Queries are directed to
MainRepositoryjob, but the job is skipped. This is because
GroupServerSkipIfCanQuery=true, and the repository can be queried. Queries continue to be directed to
GroupServerSkipIfCanQuery=true, the repository cannot currently be queried (due to
GroupServerRedirectedQueriesOnly=TRUE), so the job is allowed to run.
SecondaryRepositoryjob completes. Queries to
MainRepositoryare now redirected to the datastore for
MainRepositoryjob. The job runs this time because queries to it are currently redirected to
MainRepositoryjob completes. Queries to
MainRepositoryare now redirected back to the datastore for
SecondaryRepositoryjob runs. Before the job starts the datastore is cleared (due to
GroupServerClearDatastoreOnStart=TRUE). On completion queries to
MainRepositoryare redirected to the
MainRepositoryjob runs. Before starting the datastore is cleared (due to
GroupServerClearDatastoreOnStart=TRUE). On completion, queries to
MainRepositoryare redirected to the
Steps 7 and 8 repeat until the service is stopped or an error occurs.
If an error occurs which means that the update was not successful (for example the job could not connect to the data source), redirection does not occur. The next job does not run because its datastore is being used for queries. This means that there is no break in service, however until a job is successful OmniGroupServer will not have the latest user and group data.
If OmniGroupServer is stopped, when it restarts it begins again from step 1. However, the
MainRepository datastore is already populated so can immediately return results (though the information does not include the latest changes).
The example configuration above could be extended to more than two repositories by creating copies of the
SecondaryRepository job and adjusting the start times accordingly.