Chapter 6 The ConceptBase.cc Server
The ConceptBase.cc server (CBserver) offers its services via a TCP/IP port to client
programs.
The main services are to TELL or UNTELL O-Telos objects
and to ASK queries to the database. The operations are called by clients
(for example, the user interfaces described in section 8).
An arbitrary number of clients can connect to a CBserver.
The CBserver is started1
by a command line
cbserver <params>
assuming that the installation directory of ConceptBase.cc is
added to the search path of executable programs. If it is not on the
search path, then simply change the current directory to the installation
directory of ConceptBase.cc or use its absolute path of the cbserver script.
6.1 CBserver parameters
The following parameters are available for the ’cbserver’ command:
-
-d dbdir
- Set database dbdir to be loaded. If the database does not exist it
is created and initialized with the O-Telos pre-defined objects.
A database is maintained as a directory. The parameter is mandatory
except when the update mode is set to nonpersistent (see below).
You cannot start two concurrent servers which use the same database directory.
To avoid this case, a file OB.lock is created in the database directory
when the first server is started. If the server crashes during its execution,
the file OB.lock will still exist in the directory. Before you
restart the server, you might have to remove this file manually.
- -db dbdir
- Like -d but also sets the load/save/views directories to
dbdir, i.e. the CBserver will automatically maintain the module sources
in dbdir and also materialize the selected queries in the same directory.
See section 5.9 for details.
- -u updatemode
- controls update persistency.
The allowed values are persistent and nonpersistent.
If no database is provided by parameter "-d", then the default
update mode is set to nonpersistent. Otherwise, the default is
persistent.
In nonpersistent mode, all updates are lost after the ConceptBase server
is stopped. In persistent mode, updates are stored in the files of the database and
will be available for future sessions.
- -U untellmode
- controls the way how UNTELL is executed by the server.
The allowed values are verbatim and cleanup (default).
In verbatim mode, the UNTELL operation will only untell the facts
directly described by the O-Telos frame being submitted as argument.
In cleanup mode, UNTELL will also try to remove the instantiation to the
O-Telos system classes Individual, Attribute, InstanceOf and IsA.
By doing so, UNTELL behaves inverse to the TELL
operation. More details are explained in subsection 6.4.
- -port portnr
- sets the TCP/IP socket portnumber for client connections
to the CBserver. The value portnr
must be between 2000 and 65535. If there is already a process using the
portnumber, the CBserver will abort2. The default value for
the portnumber is 4001.
- -p portnr
- is the same as "-port portnr". Deprecated since it conflicts with
a predefined command line parameter of SWI-Prolog.
- -t tracemode
- sets the tracemode of the CBserver.
It is one of silent, no, minimal, low, high, veryhigh. The tracemode
determines the amount of text displayed by the server during its execution.
The tracemode does not influence the function but is used for debugging. The
default tracemode is set to low (display CBserver interface calls plus their answer).
The tracemode minimal will configure the CBserver to only trace the CBserver interface
calls (without answers), and the tracemode no virtually disables tracing.
The tracemode silent is even surpressing the message ’CBserver ready’ when starting up
the CBserver.
The tracemode high and veryhigh are useful for debugging the system.
In these two modes, an unlikely fatal signal like division by zero will not directly abort the
CBserver process but start a debug dialog. Enter "h" for options to
diagnose the problem in collaboration with the ConceptBase developers.
- -c cachemode
- turns on the query cache to allow recursive query evaluation.
The value cachemode is one of off, transient, and keep (default).
In transient mode the cache is emptied before each transaction. In keep mode,
the cache is emptied when the maximum number of entries in the cache is exceeded
or an update has invalidated the cache. Further details are explained in section 6.2.
- -o optmode
- controls the optimizer for rules, constraints and queries.
The value optmode is one of 0 (no optimization), 1
(structural optimization by exploiting builtin O-Telos axioms),
2 (optimizing join order) or 3 (combines 1 and 2). Default
and recommended is 3.
- -r secs
- automatically restarts the server after a crash.
The value secs specifies how many seconds to wait before restart.
Crashes are infrequent with the CBserver. Use this option
only when you want maximum accessibility of the server. This option
is not available on Microsoft Windows.
- -s securitylevel
- configures the access control mechanism of
ConceptBase. The value 0 means that no access control is employed.
Any user can ask, tell, untell, retell any object in any module. You
can also untell objects defined in a super-module.
Level 1 (default) provides a very basic protection: one can only
untell objects when the are defined in the current module. This
prevents in particular undesired deletions of objects defined in
the System module.
Level 2 fully enables access control. First, untelling of objects must
happen in the module where the object has been defined. Second, any
transaction submitted by a user to the CBserver is checked against the
permission rules as defined in section 5.6. Enable access control
when you use ConceptBase in a multi-user setting and you want to avoid errorneous
interferences between different users.
- -e maxerrors
- sets the maximum number of errors to be displayed to a ConceptBase.cc
client within one transaction. The value -1 means that no restriction is applied.
Set to 0 to surpress any errors message and to a positive number to limit the
displayed errors messages to that number. A low positive number can speed up the
communication between ConceptBase client and server if a lot of error messages
are generated. The default is 20.
- -cc ccmode
- (predicate typing) controls to which extent the CBserver
applies strict typing of
attribution predicates (x m y) occurring in the membership constraints
of query classes.
If the mode is set to strict (=default), attribution predicates without a unique
concerned class3
shall not be accepted.
If the mode is set to extended, the search for concerned classes shall include
subclasses (see section 2.2.7).
If the mode is set to off, ConceptBase.cc
also accepts queries with unstrictly-typed attribution predicates.
The strict mode is preferable since it avoids certain semantic errors.
Deduction rules and integrity constraints may never violate the
predicate typing condition, even if the mode is set to off.
An example for a query using non-strict predicate typing is available from
the CB-Forum, see link.
- -mu mumode
- (multi-user mode) specifies whether the CBerver should
run in multi-user mode (value enabled) or in single-user model (value disabled).
By default, the multi-user mode is enabled, allowing multiple users with different user
names to connect to the CBserver. In single-user mode, only clients started
by the same user (identified by her name) can connect to the CBserver.
The single-user mode is recommended if you want to block other users from logging
into your CBserver. Since the test is done only on the user name, a malicious
attacker could use your user name for an account on another computer and then
successfully log into your CBserver. Use Internet firewalls to protect
against such attacks.
- -v vmode
- controls whether view maintenance rules are generated (vmode=on)
or not (vmode=off). View maintenance rules are used to keep a ConceptBase.cc
view up-to-date upon changes to the object base. Default value for vmode is off.
- -mc maxcost
- this parameter defines the maximum cost level for a predicate in a
binding path that is used to compile a meta formula (see section 2.2.9).
The evaulation of a binding path yields fillers for the meta variables. Set maxcost to
10 if such a predicate should have about one free variable. Set it to 100 if
if may have two free variables. Default is 100. The higher the number, the more
candidate paths are generated, increasing the likelihood that a binding path is
found. On the downside, a high value increases the compile time of meta formulas.
- -pl pathlen
- sets a maximum length for binding path candidates. In principle,
the number of candidates can explode with the path length. Like the previous parameter,
the path length influences the ability of ConceptBase.cc to compile meta formulas. The
default value is 5. If you set the value to 0, then no meta formula can be compiled.
- -im imax
- sets the maximum number of iterations used to re-order attribution
predicates with one free variable. Evaluating such predicates first can lead
to faster elimination of free variables and thus lead to better query and ECA
performance. The default value is 3.
- -eca emode
- controls the ECA sub-system. Possible values are unsafe
(ECArules are evaluated without safeguarding
recursive deductive rules), off
(ECArules are not evaluated, even if some are defined), and safe
(ECA rules are evaluated with safeguarding recursive rules; this is the default).
Use the mode unsafe if none of your ECArules calls recursive predicates
on the newest database state. This may lead to a limited speed-up.
- -eo eomode
- controls the optimization of conditions of ECArules.
Possible values are on (default) and off. The optimization is done by
a re-ordering of predicates in the condition. Hence, you only want to turn of
optimization to gain full control over the order of evalution in ECA conditions.
- -load dir
- specifies the directory from which the CBserver will load
module sources at start-up time. The module sources must have file names
starting with System and file type sml. Typically, they are
generated via the -save flag in the preceding session of the CBserver.
The default is none, i.e. no module sources are loaded at CBserver
start-up.
- -save dir
- specifies the directory into which to save certain textual
excerpts of the database, in particular module listings. The parameter has the
default value none, which disables the saving function. Currently,
the CBserver only saves module listings. Each module is stored in one
file with file type sml. The directory dir must exist.
The module listing is performed when the CBserver is shut down (complete module
tree is listed), or when a client tool logs out (home directory tree of
the client tool is listed). The module listings uses the set module
directive to enable the import of the file to the right module location.
- -views dir
- specifies the directory into which the results of certain
queries are materialized. See section 5.9 for details.
- -rl rlmode
- controls the way how the CBserver creates labels for generated formulas.
The default value is on, instructing the CBserver to find a readable
label for the generated formula. It typically consists of the labels of
the participating metaclass attributes occuring in the metaformula.
If set to off, the CBserver will just take a system-generated label that contains
a unique identifier. This is slightly less readable (if you want to inspect
the generated formulas) but safe against certain possibilities of assigning
the same label twice.
- -g cmd
- provides a special command to the CBserver. There are currently
two such commands. The command nolpi instructs the CBserver to ignore
any plug-in file (see section F). The command
exit instructs the CBserver to exit immediately after start-up. This can
be useful to combination with the option -views, -db and -save
to materialize some excerpts from a stored database.
The trace of the CBserver can be saved by redirecting its
output, e.g.
cbserver -r 10 -port 4444 -t high -d MYDB >> mylogfile.log
The CBserver can also be started directly from the ConceptBase.cc
User Interface (see section 8) and most parameters can
be specified interactively. The command line version is recommended when
one CBserver serves multiple users or when user interface and server shall run
on different machines.
Note that some features like persistency can be disabled depending on your licence.
A corresponding message is displayed in the window where you start the
ConceptBase server.
A frequent error message during the startup of the CBserver
is the following:
### FATAL ERROR:
Application is locked by hostname, PID 1234
### CBserver aborted
This messsage is printed if there is still a file with the name OB.lock
in the database directory (option -d). The OB.lock file should avoid that
two servers are using the same database directory. The file may be left over of a previous
CBserver if the server was not stopped correctly (e.g. aborted by Ctrl-C or it crashed).
If you get this error message, make sure that there is no other server running
that uses this directory and then delete the file OB.lock. Then, the
CBserver should start correctly.
6.2 The tabling subsystem
Since version V5.2.4 ConceptBase.cc features a new query evaluation method,
which uses a so-called tabling cache to store intermediate results of predicates
that are called during the top-down (SLDNF) query evaluation. Assume, for example, that
an employee ’bill’ has two projects ’p1’ and ’p2’. Then, the
result of a predicate ’(bill hasProject x)’ with variable x would be
the set {(bill hasProject p1),(bill hasProject p2)} consisting of facts.
We call this fact set also the extension of the predicate.
After a completed predicate evaluation, the tabling cache of the predicate holds
its extension. Tabling speeds up query evaluation and
prevents infinite loops when ConceptBase.cc evaluates
recursive queries and deductive rules. Essentially, the
tabled evaluation allows to compute dynamically stratified
semantics of the Datalog database underlying ConceptBase.cc.
Plenty of examples for recursive rules and queries are provided
in the online ConceptBase Forum.
The CBserver provides three tabling cache modes to control the
behavior during query evaluation:
- -c off
- In this mode, the cache is completely disabled. Use this mode
when your models do not include recursive rules.
The mode is only provided for backward compatibility and has no advantages.
- -c keep
- The cache is only emptied when necessary, i.e. when the cache
has been invalidated by an update to the database, or when the maximum number
of facts in the cache is exceeded. The maximum number is currently set
to 50000. If necessary, the cache emptying takes place before
a transaction. The keep mode is on average consuming more main memory than the
transient mode but speeds up response time enormously in case of re-use of query
results.
- -c transient
- The tabling cache is emptied before
each transaction (ask, tell, untell, retell). A subsequent query is always
evaluated starting with an empty cache. This mode is somewhat ’safer’ than the
’keep’ mode since it starts each query with an empty cache state.
While the answer to a query is in principal independent from the cache mode,
the cache mode has a certain influence on the persistence of objects created
within a transaction. Specifically, results of arithmetic expressions
computed during one transaction shall be removed after the transaction
when the cache mode is ’transient’. In cache mode ’keep’, these objects
continue to exist and are visible to future transactions.
ConceptBase will only call tabled evaluation for deductive predicates.
Other predicates are evaluated by the regular SLDNF engine of the
underlying Prolog engine.
By default, the tabling cache mode is activated in mode keep.
Some statistics on cache usage are written to the terminal window of
the ConceptBase server when the tracemode has been set to veryhigh.
Acknowledgements: The techniques for the
tabled query evaluator of ConceptBase.cc are inspired by the ’tabled evaluation’ [SSW94, CW96].
We do however not delay the evaluation of negated predicates but rather re-order
them at compile time to guarantee that all variables are bound at call time.
Tabled evaluation is also implemented in XSB [link]
and DES [link].
6.3 Database persistency
The default update mode is ’persistent’. In persistent mode, all changes
to the database are written to the file system at the directory specified in
the parameter ’-d’. Persistent mode is suitable when a CBserver
runs for a longer period of time and is directly updated by
application programs.
If ConceptBase.cc is used for testing and modeling
purposes, the update mode ’nonpersistent’ is an interesting alternative.
We discuss two scenarios for the nonpersistent mode and one for the
persistent mode.
Scenario 1: Single-user modeling. When a user needs to model a certain
application domain with classes and meta classes, he usually works
with external Telos files (aka source models, file extension ’.sml’).
These files can include comments like usual with program source code.
The recommended mode here is ’-u nonpersistent’ without specifying a
database. The user can load the source models
into such a non-persistent server and make corrections to the source
files in case of errors or design changes. Here, ConceptBase is
mostly used to check and analyze the models.
Recommended options:
cbserver -u nonpersistent -mu disabled
Scenario 2: Lab assignments.
Assume that a teacher wants students to exercise a certain modelling task
using ConceptBase.cc. Then, he would prepare some Telos files with necessary
definitions (e.g. some meta classes) and load them into a persistent
ConceptBase server. After that, he can restart the ConceptBase server
in non-persistent mode on the same database created before. Student
can then work on their extensions while the state of the database
can easily be set back to the original state defined by the teacher.
The module system of ConceptBase.cc can be used to support multiple
students to work on the same server without interfering with each other,
see section 5.
Recommended options:
cbserver -d MYDB -s 2 -mu enabled -u nonpersistent
The second scenario might also be useful in modeling. If there are some
parts that are regarded as stable, the modeller can decide to make
them persistent and only add/modify those Telos models that are still
subject to change. In particular for large Telos models, this strategy
saves time.
Note that the updates by the users are lost when the non-persistent
CBserver is stopped. This might be useful, if you want to re-use the same
initial database MYDB several times, e.g. for different user groups.
Scenario 3: Project work.
Here the students work for several days on a given task. Changes shall
not be lost. The use of the -db option will not only store the database
in binary form but also store the source code of all modules as text
files in directory MYDB.
Recommended options:
cbserver -db MYDB -s 2 -mu enabled
If ConceptBase.cc is used in a multi-user setting, then one can combine
the update mode with the module feature (see section 5).
In this scenario, multiple users access the same CBserver.
A common super module (e.g. the module oHome) carries the common
objects of the users. Each user can be assigned to her own hown module
(a sub module of the common super module) and create and update
objects in this workspace without interfering with other users.
If several groups of users shall share their definitions, then they would
be assigned to the same home module. The home module may have sub modules
for testing and releasing definitions. By employing access rights to
modules, one can also design which user has which read/write permissions.
The builtin query listModule allows to save the contents of a
module to a Telos source file (see section 5.7).
6.4 The UNTELL operation
ConceptBase.cc realizes the concept of a historical database. The TELL operation
submits O-Telos frames to the CBserver. The CBserver extracts the ’novelty’
of the submitted frames and translates it into a set of P-facts to be stored
in the object store. Any P-fact has a so-called belief time associated to
it (see section 2.1). The belief time is an interval (t1,t2) whose left boundary t1 is the time point when
the P-fact was inserted to the object store, i.e. the time when the transaction
was executed that led to the insertion of the P-fact. The right boundary t2 specifies
the time point after which the CBserver assumes the P-fact to be not true anymore.
It is initialized with ’Now’ when the P-fact is created. This symbolic value
is interpreted as the current time. You may also interpret such a time interval to be right
open.
The UNTELL operation terminates the belief time of P-facts specified in an O-Telos
frame. The value
’Now’ is replaced by the time4
when the UNTELL operation is executed.
From the user’s perspective, a TELL operation is about creating some objects and
the UNTELL operation is about deleting them5. Many users expect the UNTELL operation to be symmetric to the TELL operation,
i.e. untelling a frame that has been told before should remove the frame completely.
This is however not the case for the following reasons:
-
An O-Telos frame being argument of a TELL or UNTELL operation is not necessarily all
the information about an object but just some.
- Other objects might refer to an object told previously. An UNTELL operation would then
be rejected to preserve referential integrity.
- ConceptBase.cc adds instantiation to the builtin classes Individual,
Attribute, InstanceOf, and IsA depending on the type of the object.
The last reason is most significant in preventing symmetry. As an example consider the O-Telos
frame (referred to as frame 1).
bill in Employee with
name
bname: "William"
end
ConceptBase.cc will recognize that bill is an individual and that bill!bname is an
attribute. This information is attached internally to the P-facts, more precisely, it is derivable
from the structure of the corresponding P-facts. When you ASK the system for the frame of bill
after the TELL operation on frame 1, you will get frame 2:
Individual bill in Employee with
attribute,name
bname: "William"
end
Hence, the instatiation to the four builtin classes is added to the frame. If we submit the original
frame 1 to an UNTELL operation, ConceptBase.cc assumes by default that only two facts should be untold:
-
The instantiation of bill to Employee.
- The instantiation of the attribute bill!bname to its attribute category Employee!name.
As a consequence, the object bill and its attribute continue to exist after the UNTELL on frame 1.
It would look like (frame 3):
Individual bill with
attribute
bname: "William"
end
Only by untelling this frame 3 as a second operation or by untelling the completed frame 2, the
object bill and its attribute bill!bname shall be made historical.
This assymmetry of TELL and UNTELL is regarded by some ConceptBase.cc users as unnatural behavior.
They expect that an UNTELL is also supposed to affect the objects themselves, not just their
instantiation to classes. To support those users, we provide a so-called untell mode (see parameter
-U in the list of CBserver command line parameters). The untell mode is verbatim will cause
ConceptBase.cc to behave as explained above.
The mode cleanup (default) will take care to remove the objects themselves
provided that they have no other instantiations to classes except instantiation to the four
builtin classes Individual, Attribute, InstanceOf, and IsA. Furthermore,
no other object may be linked to the object subject to be untold.
6.4.1 Cascading UNTELL
You can use ECArules to realize a cascading UNTELL, i.e. if an object is deleted then
all its links to other objects are deleted as well, leading to potential follow-up deletions.
The required ECArules are provided in
link.
You only need to add the ECArules to your database to enact the cascading UNTELL.
You should be careful with using the cascading UNTELL. For example, untelling
a system class will also untell all instantiations to it. Use the CBserver
option -s 1 to prevent such undesired deletions.
6.5 Memory consumption and performance
ConceptBase.cc stores objects in a dedicated object store maintained in
main memory. A P-fact P(o,x,n,y) consumes about 800 bytes of main memory.
That means that one can store roughly 1 million P-facts in 1 GB of main memory.
A typical Telos frame is stored with roughly 10 P-facts. Hence, 1 GB of main
memory allows you to store around 100.000 Telos frames.
On 32 bit CPUs, this results in a maximum of roughly 400.000 frames that
can fit into 4 GB of addressable main memory. This restriction virtually
vanishes with 64 bit CPUs.
A single TELL/UNTELL operation submitted to the CBserver should
not contain more than about 2000 frames (at about 5 attributes per frame).
Otherwise, the compiler can run out of stack memory.
The raw performance of the object store, i.e. the time needed to reconstruct a
frame for a given object identifier, is virtually independent from
the number of P-facts that it stores. However, if you have defined many rules
or integrity constraints, the performance may well degrade significantly
with the number of stored P-facts. The same holds for queries.
We tested the response times for standard queries such as computing the
transitive closure in relation to varying database sizes. Results indicate that
ConceptBase apparently approximates in many cases the theoretic optimum.
The performance of the active rule evaluator (section 4) is currently
rather limited. We measured around 100 rule firings per second. This can be a
performance bottleneck when many active rules are being processed.