Skip to main content
Skip table of contents

ROAD Service and Database

ROAD uses the no-SQL database MongoDB. All ROAD Service installations inside a ROAD cluster share a common database instance. No other ROAD process accesses the database; the only other components accessing it are the ROAD setup, some scripts and general MongoDB maintenance tools.

As a professional database management system MongoDB provides lots of different tools and installation architectures like replica sets to have several redundant database instances being replicated and providing failover support.

ROAD doesn’t care for those database management internals. It is directed to use an instance by its configured database connection string.

When and How Does the ROAD Service Access the Database?

When a ROAD Service instance is starting (usually as a Windows service when Windows starts), it tries to connect the database by the configured connection string, which mainly contains the URI of the MongoDB service (and some optional stuff like URIs to other MongoDB services). In case this connection fails, the ROAD Service will continue running in a restricted mode. The same occurs if a database disconnect is detected later.

After the first successful connection to the database, the ROAD Service reads the list of all other ROAD hosts in this cluster and updates its own host info there. Then the schedule runner starts for the first time (and repeats with a cycle of 10 minutes by default). Now the ROAD Service is fully available for all clients requests.

Disconnected Mode

If the ROAD Service was already connected since it’s running, it allows manipulations on active jobs on its own host. The ROAD Service maintains a local cache for active jobs, which allows basic queries and will be written back when the connection is reestablished (but will be lost in case the Service is shutdown before).

Most other client requests will run into errors because the database must be connected to do a query.

If the ROAD Service was not yet connected and couldn’t initialize basic information, it will retry in a cycle (default 1 minute), but cannot run any job.

Losing Connection

A break of the connection to the database is either detected in a cycle or when a database request fails (with some timeout delay). The Service is only partially accessible then until the connection is reestablished.

Automatic Data Maintenance

Host Info

When the ROAD Service is active, it repeatedly updates the info about its instance in the database, so other hosts in the cluster can access basic information about it (this is crucial for relaying requests and subscriptions). A basic parameter for this is UpdateHostAliveInterval from RoadService.exe.config.

The Service also repeatedly updates its cached information about the others in the cluster. If it detects that another host didn’t update its own information in time (with some tolerance), this will be marked as inactive.

Stored Jobs

When the ROAD Service is launching, it looks for jobs it created in the database, which are still marked as active. This is an invalid state because jobs will terminated when the Service stops and can only occur if the Service or Worker was stopped irregularly. Those jobs' state is automatically repaired when this Service instance starts the next time: The CurrentState will be set to “Terminated” and the IsActive flag to false.

Note in case a host isn’t used any more in the ROAD cluster or its name or alias changed, so there is no responsible instance any more, a manually triggered repair is possible via the jobs API.

JavaScript errors detected

Please note, these errors can depend on your browser setup.

If this problem persists, please contact our support.