# Configure Redirection

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:

1. When OmniGroupServer is started, both `MainRepository` and `SecondaryRepository` are empty. Queries are directed to `MainRepository`.
2. At 06:00 OmniGroupServer attempts to run the `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`.
3. At 18:00 OmniGroupServer attempts to run the `SecondaryRepository` job. Although `GroupServerSkipIfCanQuery=true`, the repository cannot currently be queried (due to `GroupServerRedirectedQueriesOnly=TRUE`), so the job is allowed to run.
4. Some time later the `SecondaryRepository` job completes. Queries to `MainRepository` are now redirected to the datastore for `SecondaryRepository` (due to `GroupServerRedirectOnCompletion=MainRepository`).
5. The next day at 06:00, OmniGroupServer attempts to run the `MainRepository` job. The job runs this time because queries to it are currently redirected to `SecondaryRepository`.
6. Some time later, the `MainRepository` job completes. Queries to `MainRepository` are now redirected back to the datastore for `MainRepository` (due to `GroupServerRedirectOnCompletion=MainRepository`).
7. At 18:00, the `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.
8. The next day at 06:00, the `MainRepository` job runs. Before starting the datastore is cleared (due to `GroupServerClearDatastoreOnStart=TRUE`). On completion, queries to `MainRepository` are redirected to the `MainRepository` datastore.

9. 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.

_FT_HTML5_bannerTitle.htm