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.
TIP: 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 MainRepository
and SecondaryRepository
.
[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:
MainRepository
and SecondaryRepository
are empty. Queries are directed to MainRepository
.MainRepository
job, but the job is skipped. This is because GroupServerSkipIfCanQuery=true
, and the repository can be queried. Queries continue to be directed to MainRepository
.SecondaryRepository
job. Although GroupServerSkipIfCanQuery=true
, the repository cannot currently be queried (due to GroupServerRedirectedQueriesOnly=TRUE
), so the job is allowed to run.SecondaryRepository
job completes. Queries to MainRepository
are now redirected to the datastore for SecondaryRepository
(due to GroupServerRedirectOnCompletion=MainRepository
).MainRepository
job. The job runs this time because queries to it are currently redirected to SecondaryRepository
.MainRepository
job completes. Queries to MainRepository
are now redirected back to the datastore for MainRepository
(due to GroupServerRedirectOnCompletion=MainRepository
).SecondaryRepository
job runs. Before the job starts the datastore is cleared (due to GroupServerClearDatastoreOnStart=TRUE
). On completion queries to MainRepository
are redirected to the SecondaryRepository
datastore.MainRepository
job runs. Before starting the datastore is cleared (due to GroupServerClearDatastoreOnStart=TRUE
). On completion, queries to MainRepository
are redirected to the MainRepository
datastore.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.