Evaluación comparativa

The three example systems in the last section each attempt to provide a type secure persistent store. However, the Argus and Texas Instruments systems both fall short of the ideal system since they allow some of the physical properties of data to be visible. In Argus, this includes whether the data is stable and where the data is physically located in a network. Similarly, the Texas Instruments system allows a programmer to distinguish objects that are more resilient than others. This aspect of the two systems violates the persistence abstraction and would be hidden in an ideal system. Despite these criticisms, the three example systems each provide a good approximation to the ideal type secure persistent store.

The remainder of this thesis presents the development of a layered architecture that will support experimental implementations of an ideal persistent system. The structure of the layered architecture has been designed for use with a high level programming language that provides the resulting system's protection mechanisms, as discussed in Section 2.1. Furthermore, the interfaces to the individual architectural layers have been organised in such a way that the layer implementations may be freely changed independently of each other. Thus, the illusion of unbounded space can be provided by any one of the techniques described in Section 2.2, without exerting undue influence on the provision of stable storage using the techniques described in Section 2.4, or any attempts to provide an illusion of infinite speed, as described in Section 2.3.

It is envisaged that any system constructed from the layered architecture should be able to meet the requirements of an ideal persistent system. That is, the resulting persistent system should be based on a type secure stable store whose physical properties are completely hidden from the programmer.

3 The CPOMS

The CPOMS is a persistent object management system written in C and is part of the PS-algol interpreter[psa85]. Its purpose is to provide the interpreter with an implementation of the kind of transactionally secure persistent store described in Chapter 1. It was designed as an experiment in implementing such a store to investigate the interaction between the various components of a persistent system. These components include a programming language, a type system, a transaction mechanism, a concurrency mechanism and a stable persistent store.

The persistent store implemented by the CPOMS was originally designed for use with applications that operate on several large disjoint pieces of data, but only need to be able to update one of them. To support this the persistent store is organised into units called

databases.

There is a copy of the PS-algol interpreter for every active PS-algol program. Since the CPOMS is part of the PS-algol interpreter, there is also a copy of it for each active PS-algol program. Therefore the databases, which are passive, are operated on by multiple copies of the CPOMS, as shown in Figure 3.1. To ensure that PS-algol programs do not interfere with each other, a database may be accessed by only one program at a time if it is to be updated, or by several programs if it is only to be read. This is achieved by locking a database when it is first accessed, to indicate its intended use. To complement this, updates to the persistent store are performed only if all the databases that a program wishes to change are locked for updating.

In addition to controlling the sharing of data, the databases also provide the mechanism for identifying persistent data. That is, each database is used as a root of persistence, so that any object reachable from the first object in a database persists. The first object in a database is known as the root object.

Database Locks Program 1 CPOMS 1 Program m CPOMS m Database 1

The Persistent Store

Database n

Figure 3.1. The interaction between the CPOMS and the persistent store.

To assist the organisation of the persistent store, the databases are identified by unique names. This naming facility is complemented by password protection to allow individual users to restrict access to private data. Thus, to access the persistent store, a program must identify a named database and supply the appropriate password. Once the named database has been identified and the password checked, the address of the database’s root object is returned. This allows all data in the persistent store reachable from this root object to be accessed by the program.

To ensure that the data held in the persistent store remains self-consistent, a transaction mechanism is provided to control the updating of databases. This mechanism works by giving each program using the persistent store a copy of each object that it accesses. A commit algorithm may be invoked by a program to copy any objects it has changed back to their databases. This algorithm is structured so that either all the changed objects are written back or none of them are. In addition, checks are made to ensure that no objects are copied back to a database unless the program invoking the commit had opened the database with the intention of updating it.

The persistent store is accessed by a PS-algol program using a set of interface procedures provided by the CPOMS. These procedures, open.database, create.database and commit,

allow a program to open a named database indicating whether or not it is to be updated, to create a new database or to invoke the commit algorithm, respectively. Since the address of the root object in a database is returned when the database is opened, no explicit interface need be provided to access individual objects. This can be performed automatically when an object is dereferenced. Hence, a PS-algol program can access individual objects by simply following object addresses starting from the database's root object.