Getting Started

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

XSB Version 1.7.1 (7/10/97)

[Solaris, optimal mode]

| ?- [load].

[load loaded]

yes

| ?- init.

[ctr loaded]

[updates loaded]

[parser loaded]

[upload loaded]

[optim1 loaded]

[optim2 loaded]

yes

| ?-
 

Prototype Commands

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. 

Compilation Commands

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. 

Optimization Commands

After a CTR program has been compiled, the first optimization---backtracking elimination---can be invoked using the command: 

    opt1_trans(program_name)

 It modifies the transaction-base object file, and creates the optimized file:     

    program_name.opt1.o 

Query compilation, the second optimization, can then be performed on CTR programs, with the following command: 

    opt2_trans(program_name) 

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 

Execution Command 

A CTR goal defined in the transaction base file is submitted for execution using the command exec, with the format: 

    exec(Goal). 

Prototype Syntax

CTR Rules 

The transaction base rules, or CTR rules, have a rule head and a rule body with the syntax:

    Head :- Body. 
    or 
    Head. 

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

Database Rules 

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. 

Database Declaration 

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: 

    updatable Name/Narg. 

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:

   monitor(Task). 

and displays messages when monitor executes or rolls back.