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:

  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:

  ri:addenv/2, %add an env.
  ri:delenv/1, %delete an env.
  ri:setenv/2  %set an env.
  

• Managing graphs (advanced topic):

  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:

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