Skip to content

ODA Configuration Database

rPraml edited this page Nov 28, 2014 · 2 revisions

This is only a summary of the Skype discussion from Nov-28/2014

Consider all information on this site with reservation!

XOTS

For XOTS, there is demand to store persistent information across replicas. Approaches like storing the Xots-Tasklet information in the NSF were discarded, because it is not easy to maintain and needs some overhead (lookup views....)

So the first idea was, to store that in a central NSF (XotsManager.nsf) that has to be installed on all replicas. (There was also the idea to store that data in the catalog.nsf ;) )

Logging

For Logging, we have also demand to store persistent information. (What class should be logged and so on) So it opens up to store all that information in a common database (e.g. ODA.nsf, name not fix!) The ODA Nsf can interact also as log target (optional, because log files may cause heavy replication load)

Initialization of the XOTS Tasklets

Optimal: The NSFScanner tries to figure out if xots is enabled by scanning the "WEB-INF/xsp.properties". This must be done in an efficient way (without loading the whole module) TODO: What flag should be checked - how to handle XPage templages

Fallback: The $Xots item in the Icon indicates if it is a xots enabled DB or not.

Xots-Instance configuration

To maintain global configuration, each Xots instance (on each cluster server) has a settings document. A settings document has the fields

  • serverName
  • xotsThreads (how many worker threads does the ThreadPoolExecutor start)
  • alias (see below, any server should be able to be tagged as MASTER or SLAVE. This may be important in cluster environment)
  • nsfScan (Interval, how often the NSFScanner should run and check for new tasklets)

Xots NSF Scanner

If the NSFScanner detects a Xots-enabled database, it scans ALL classes for the @Tasklet annotation and creates/updates a control document in the ODA.nsf. (This is done only if a design change is detected) A control document has the fields

  • state (could be enabled/disabled)
  • lastRun (to handle intervals correctly on server restart)
  • schedule (this setting is copied from the @Tasklet annotation)
  • scheduleOverride (an alternative setting. @Tasklet may control if override is allowed or not)
  • replicaID (replica id + className is the primary key)
  • modulePath
  • runOnServer (can be * also, or maybe an alias like MASTER/SLAVE)
  • className
  • additional statistic data (last run time..., cpu consumption)
  • Form = "XotsTasklet"
  • ...