= Configurable Job Server = == About the job server == A job server is is an application server used to take control the arriving requests. The concept is similar to the 'Readers-writers problem'. If a new request is arrived to the server, the type of the request has to be determined. It can be a modifier or a non-modifier. If a request modify the database, then it is called modifier, else it is called non-modifier. After the type of the request has been determined, the permission of the execution should be limited, as described below. A modifier can only be executed when nothing else is running. A non-modifier can only not be executed when a modifier is running. Consider the following examples: * A long running semantic query has been started from the {{{ri}}} module. Until the query has not been finished, nobody can add files from the {{{ri}}} module nor from the web interface, but another semantic query or a dependency examination can be started from any interface. * Database synchronization has been started from the web interface. Until the synchronization has not been finished, nobody can run a semantic query, can add content to the database from any interface. A list of the groups of modifiers is given below. Every operation, which belongs to one of the listed groups, is demonstrated by giving the corresponding function from the {{{ri}}} module. We note that all of the user interfaces of the !RefactorErl is supervised by the same job server, so the same rules apply to them. * Managing the content of the database: {{{#!erlang ri:reset/0, ri:reset/1, % reset the database ri:add/1, ri:add/2, % add content ri:drop/1, % drop content ri:backup/0, ri:backup/1, % make a backup ri:undo/0, % undo ri:restore/1, % restore previous backup ri:database_synchronization/0, % synchronize the database }}} * Managing environmental nodes: {{{#!erlang ri:addenv/2, %add an env. ri:delenv/1, %delete an env. ri:setenv/2 %set an env. }}} * Managing graphs (advanced topic): {{{#!erlang ri:create_graph/1, % create a new graph ri:rename_graph/2, % rename a graph ri:load_graph/1, % load a graph ri:delete_graph/1, % delete a graph ri:delete_all_graphs/0 % delete all graphs }}} == How to restrict the enabled user-level operations? The blacklist is a list of denied operations. These operations can not be allowed to be run in any circumstances. The blacklist is loaded from a file, which is placed in ''data'' directory, is called ''ui_router_blacklist'' and is processed with ''file:consult'', during the initialization of the job server. A valid blacklist for example: {{{#!erlang [add, drop, reset, add_dir, drop_dir]. }}} If this blacklist is present, then nobody can add to / can delete anything from the database and nobody can reset the database.