Like template applications, multiple segments can be described by single database object of the TemplateSegment class. Such segments are mainly introduced by needs of the trigger configuration description, where the only difference between configurations for different trigger racks is defined by trigger processing unit objects (i.e. TPU computers). The template segments are generated on-fly by DAL algorithms. The number of template segments is defined by number of rack objects included via "Racks" relationship. A name of such segment is generated as "segment-db-id:rack-db-id" and the hosts of such segment are defined by "Nodes" relationship of the rack object. A template segment may have template applications only. A template segment may not have nested segments or explicitly defined hosts. Individual template segment can be disabled, if corresponding rack object is put into partition's "Disabled" relationship.
A segment object defines computers, where applications without
explicitly defined hosts are running. Such computers are defined
via "Hosts" relationship for a normal segment and via "Nodes"
relationship of corresponding rack object for a template segment.
This relationship points to the objects of the abstract ComputerBase
class, which are instantiated either as real computers (objects of
the Computer class) of their logical unions (objects of
the ComputerSet class). The DefaultHost and the
BackupHost relationships have been removed: the default
host is the first host in state "On" of the Hosts
relationship and the backup hosts are either explicitly defined
for infrastructure applications, or first good (i.e. passed a
test) host of the Hosts relationship.
To access properties of a segment or to iterate a tree of nested segments one should use SegConfig class defined in both C++ and Java libraries. It takes into account normal and template segments of the partition as well as the partition's online segment. To get SegConfig object use get_segment() algorithms of the Partition class (see C++ and Java links). Above algorithm allows to limit depth of nested segments description (e.g. for efficiency reasons) using optional depth parameter. If the depth parameter is set to 0, then get description of this segment only (no description of nested segments is provided even if there are such segments in database). The Run Control may set depth parameter equal to 1 to get information about controller and infrastructure of nested segments to set them up. If depth parameter is used with default value, the algorithm returns description of all nested segments.
Rename ambiguous attributes as shown below:
The attribute AllowSpontaneousExit defines reaction on exit before expected moment. If the spontaneous exit is not allowed or the application exits with non-zero status, then the system will behave as specified by the IfExitsUnexpectedly attribute of the BaseApplication class.
The Application and TemplateApplication classes become abstract, since they do not define any clear lifetime policy. To port old databases to new schema the classes of existing objects in OKS files have to be renamed to appropriate CustomLifetime classes in any text editor and correct Lifetime and IfExitsUnexpectedly attribute values have to be set as required afterwards.Applications can be linked with a segment by one of the following ways: