The CTR prototype was implemented on the XSB Prolog interpreter, and consists of a number of modules. To run the implementation, the load module must first be consulted. It defines the predicate init, which compiles and loads all the modules. The following XSB session shows the output when loading the CTR prototype in XSB Prolog:
XSB Version 1.7.1 (7/10/97)
[Solaris, optimal mode]
| ?- [load].
| ?- init.
All commands for the CTR prototype are executed from the XSB interpreter. A CTR program consists of the transaction rules and database rules, which are stored in separate files:
program_name.ctr - transaction base file
program_name.db - database file
For each program, the program_name has to be the same for both transaction and database files. Both transaction base and database files must be created, even if one of them is empty.
A CTR program with the name program_name is compiled using two commands with the format:
comp_trans(program_name) - to compile the transaction base
comp_db(program_name - to compile the database
ctr_comp(program_name). - to compile and optimize a CTR program. It was created for convenience, by invoking all the compilation and optimization commands.
The compilation creates the object files:
program_name.ctr.o - transaction-base object file
program_name.db.o - database object file
The transaction base rules are parsed and compiled into a set of Prolog rules. The new rules are stored in the transaction-base object file and loaded into the Prolog database. Since the database rules are Prolog rules, they are copied to the database object file and loaded into the Prolog database.
After a CTR program has been compiled, the first optimization---backtracking elimination---can be invoked using the command:
It modifies the transaction-base object file, and creates the optimized file:
Query compilation, the second optimization, can then be performed on CTR programs, with the following command:
The output files generated by query compilation are:
program_name.opt2.o - transaction-base optimized object file
program_name.opt2.db - database optimized object file
A CTR goal defined in the transaction base file is submitted for execution using the command exec, with the format:
The transaction base rules, or CTR rules, have a rule head and a rule body with the syntax:
Head :- Body.
where Head is an atomic formula, and Body is a sequence of queries and updates connected by any of the following operators: serial conjunction (*), concurrent conjunction (#), isolation (o or o1), and disjunction (\/).
The following is an example of a CTR rule from a transaction base file:
process (I) :- task(I,1) * task(I,2) * task(I,3).
that executes three tasks sequentially.
The next rule uses logical disjunction to choose between two tasks:
process (I) :- task(I,1) \/ task(I,2).
A transaction executes a task in isolation in the following rule:
process (I) :- task(I,1) # task(I,2) # o(task(I,3)).
A database rule is any Prolog rule or atomic formula. Prolog programs are treated as elementary operations, and are executed in isolation. In practice, the interpreter can handle any Prolog rule in the database, including rules having non-logical operators. Of course, the logical semantics of CTR applies only if the database contains purely logical rules.
Built-in CTR Predicates
The prototype defines some built-in predicates, which can be invoked in the database or
the transaction base. These predicates should not be redefined by the user.
Each database tuple manipulated by a CTR program is part of a relation. For a relation to be updatable, the database must contain a declaration of the form:
This declares that a relation Name with arity Narg is updatable. Without this declararation, the prototype will not allow a CTR program to update a relation.
Transaction Base Predicates
For the database relations declared by an updatable statement, the following update commands are available in CTR:
ins(p (x)) - inserts atom p (x) into the database
del(p (x)) - deletes atom p (x) from the database
During commands execution, a task can be traced by including the monitor command in the transaction base rules. It has the syntax:
and displays messages when monitor executes or rolls back.