WO1995000907A1

WO1995000907A1 - A method of attaining data access in a primary memory based database

Info

Publication number: WO1995000907A1
Application number: PCT/SE1994/000600
Authority: WO
Inventors: Bo Mikael Samuelsson
Original assignee: Telefonaktiebolaget Lm Ericsson
Priority date: 1993-06-23
Filing date: 1994-06-17
Publication date: 1995-01-05
Also published as: FI956243A0; KR960703251A; CA2165774A1; SE9302175D0; EP0705460A1; BR9406910A; SE501433C2; JPH08512151A; SE9302175L; NO955276D0; NO955276L; FI956243A; CN1125991A; AU7088894A

Abstract

When an object (18) in a primary memory based data base (2) is accessed by a user, there is created in the user process (14) an agent object (16), that contains a reference (20) to the real object (18), and appears as if it were the real object. All accesses to the data of the object (18) are performed by reading directly, via the reference (20) in the agent object, in the memory of the storage manager (4). The data accesses are performed via a generic interface (12), in the form of read and write operations towards attributes.

Description

A method of attaining data access in a primary memory based database.

Technical field of the invention.

The present invention relates to a method for attaining data access to the data of a primary memory based data base, said data base having an operating system including a storage manager having a memory, and the data of said data base being organized as data entities containing attributes and methods. By a data entity is here meant an entity which may be of the kind object in an object-oriented data system.

When a user (client) shall access an object in a primary memory based data base data has to be transferred in some way from the data base to the user process.

Application code must not access the memory of the data base directly, due to the risk for destroying data by over¬ writing. Description of related art.

The way normally used for transferring data to the application is to create a copy in the private memory of the user process. The object is then managed as an object in the user process, which naturally suits the programming language, i.e. it is possible to read data and call methods in the object. Updatings, if any, in the object are only visible to the updating user process up to the moment when the object is written back into the data base.

In US 5,043,869 there is described a memory structure for an information processor which uses an object oriented program language. In this case there are programs in the form of data and procedure in the object. Access to the object, such as e.g. at transfer of messages is performed by addressing an object list. In the object list there is i.a the address to the object located in another memory area. At execution of the program there are required many readings from the object. For speeding up the process in case of frequent accesses some information regarding the object is added in the object list. Thereby there has been created, in a memory area separate from the memory area of the object, a list over the objects, that contains references to the objects as well as partial information of them.

EP,A2, 117,906 relates to organizing files in computer systems. The computer system has a primary and a secondary memory. The files are separated into two levels: one data level containing information blocks stored in the secondary memory and an index level which is located in the primary memory when the file is used. When the file is not used the two levels are stored in the secondary memory. When access to one side of the secondary memory is desired the index level is used, that contains index inputs with references to the blocks of the secondary memory where the page is stored. The index level thus contains references to "objects" in the secondary memory for cutting down access time.

EP,A2, 381,447 relates to a method for cutting down the access time from a memory. For increasing the performance of a computer system it is usual, in particular if the system has several users, to use virtual memory addressing (virtual memory systems) . If several programs simultanously want to access a memory area there is a risk for a conflict situation if the memory is addressed with the real physical address. Different programs could be imagined to try to write and read on the same address with probable destruction of data by writing as a result. Virtual addressing implies that the program accesses an object from the memory as if the address was the real physical address of the object in the memory. In fact there is a unit between the processor and the memory which translates the virtual address to the physical one. The unit also has the possibility of intermediate storing of these addresses for being able to organize addressing from several programs. This implies that each program can address the memory as if the program were alone in the system.

Thus it is known through the above documents to attain access to a memory area via some kind of intermediate level. In the first document this is performed by calling an object list for obtaining the address to an object, in the second document an index level is used for obtaining access to an interesting part which is stored in a secondary memory, and in the last document there is used a virtual address which is translated in a unit between the processor and the memory for obtaining access directly to the memory. Summary of the invention. One object of the invention is to provide a method of the kind indicated by way of introduction which, as compared with the state of the art, provides performance advantages, a short time of response at opening, and does not require any re-copying to the data base after updating.

In the method according to the invention a user process is opened and a generic interface is provided for the user process. A data entity in the data base is accessed from the user process by the steps of creating in the user process an agent entity that contains a reference to the real data entity, and appears as if it were the real data entity, and performing all accesses to the data of the data entity by reading directly, by means of said reference, in the memory of the storage manager. Read and write operations are performed towards the attributes of the data entity via said generic interface. Thus, in other words, when an a data entity in the data base is accessed by a user there is created in a user process only an agent entity containing a reference to the real data entity. The agent entity appears as if it were the real data entity, but all accesses to the data of the data entity are performed by reading directly, via the stored reference, in the memory of the storage manager. The data accesses are performed via a generic interface, in the form of read and write operations towards attributes.

A number of advantageous embodiments of the invention are conceivable as follows.

An opening operation for opening the data entity may include assigning to the user process a pointer to the agent entity having an interface of the real data entity as decla¬ red in a data entity type description for the data entity.

The agent entity may be created to form the reference as a pointer realized in a way enabling checking that the reference is valid.

The code for the methods of the data entity may be reached by means of a dynamic linking mechanism performed in connection with creating the agent entity, and admitting for the user process to open the data entity without need to know a class code of the data entity.

The agent entity may read the data of the data entity directly from the memory area of the storage manager.

The storage manager may be called for causing transition to a supervisor mode, in which the executed code has the possibility of writing in all parts of the memory of the pro¬ cessor, whereas the user process only has access to an own private memory area.

From a data entity type description of the data entity in a data definition language there may be generated a code for the agent entity and a description of the structure of a data base record including the data entity, for use of the description by the storage manager for managing the data of the data entity.

The attributes desired to be accessed may be identified to the storage manager by means of the agent entity.

In the generated code there may be included calls to the generic interface, in which the attributes of the data entity are identified with attribute numbers, and in the generated interface of the agent entity the same attributes may be identified in plain language by means of the attribute name used in the data entity type description.

An attribute may be declared in the data definition language by indicating its name and type, and in the generated code the attribute may be provided as two functions, one for reading and one for writing, with the same name as the declared attribute, the functions returning re¬ spectively accepting values of the same type as the declared type of the attribute.

In the description of the structure of the data base record loaded into the storage manager, the same attribute may be represented by an attribute number and a size information corresponding to the storing space of the declared type.

Brief description of the drawings.

The invention will now be described more closely by means of embodiments and with reference to the attached drawings, on which

Figure 1 schematically and in block diagram form illustrates data access according to the invention in a primary memory based data base,

Figure 2 schematically illustrates the logical, or virtual, address space in the distributed memory environment, in which the storage manager of the data base operates,

Figure 3 schematically and in block diagram form illustrates generation of code for an agent object created in a user process in accordance with the invention. Detailed description of preferred embodiments.

The data of the data base in question, generally indicated at 2 in Figures 1 and 2, are organized as data entities containing attributes and methods. In the embodiment described below it is assumed that a data entity is the same as an object in an object oriented system.

The concept of object is here intended to have the conventional meaning within the data processing art. In short an object is an information packet with an associated description of how to manage its information. The data of the object may be read either directly or by calling methods in the object. The objects are, as are also the data records, divided into classes after their area of use, and are identified by means of keys. A more detailed description of the concept of object can be found e.g. in "OBJECT-ORIENTED ANALYSIS" by Peter Coad and Edward Yourdon, Yourdon Press Computing Series.

The data base includes a storage manager 4 operating in an environment with distributed primary memory, the logical address space of which appears from Figure 2, in which to each process is assigned a private memory area 6, 6', 6"...etc., in which it has both read and write rights, it also having, however, read rights in common parts such as data base 2, code 8 and data 10 of the operating system. In the logical address space the same address may exist in the local memory of several processes, but is mapped to different addresses in the physical memory. As regards the common parts all processes have the same mapping between logical and physical address.

The possibility of providing for the process of the user (the client) right to read but not to write in the memory area of the data base makes possible realization of access to an object in the way on which the invention is based, and which will be explained closer below.

The storage manager 4 which is part of the operating system, offers towards the application a generic interface 12, below also called DMI interface (DMI= Database Manager Interface) , which shall be able to be used of all users. The DMI interface has low level character and contains i.a. no mechanisms for type security.

All access of data is performed by opening an object. Input data to the opening operation are object type, primary key and the type of access to the object that the user needs. At the opening operation the object is localized by means of the primary key, and is provided with a current type of lock. In connection therewith it is checked whether there are other processes using the object. The result of the opening operation is that the user process 14 receives a pointer 15 to an agent object 16. The agent object 16 has the interface of the real object, but does not contain any of the attributes of the object. Instead the agent object 16 contains a reference to the data of the object which are located in a data record 18 in the data base 2. The agent object 16 accesses the data base record 18 via the generic interface 12, in the form of read and write operations towards attributes. The reference to the data base record 18 is essentially a pointer 20 which, however, is realized in a way enabling checking whether the reference is valid. The code of the methods of the object are reached via a form of dynamic linking mechanism admitting that a user opening a stored object does not need to have the code of the class of the opened object linked into the same loading modul. The linking is performed in connection with creating an agent object.

The dynamic linking mechanism also admits that the opened object is a specialization with respect to that expected by the opening process. More particularly, the actual opened object may have methods and attributes not known to the opening process, and methods known by it may be realized in another way than in the basic class. The code of the specialized object type is accessed by the process by means of the dynamic linking mechanism without it needing to be known when the client code is compiled and linked. The agent object 16, below also called "DOA" (Data Object Agent) contributes with the following to the functionality of the storage manager 4:

- An interface 22, below called "DOI" (Data Object agent Interface) . - Type control in the DOI interface.

- Hiding of attribute numbers.

- Performing of updating of two-way directed references.

- Hiding of distribution and addressing.

- "Triggers", i.e. user defined routines which are executed at a certain defined event, normally an updating of an attribute in a stored object.

- Connecting up with transactions.

The function of the DMI interface 12 will now be described more closely. As has appeared from the above the object is not transferred to the user process 14 at access, but instead there is created an agent object 16, which may access the data 18 of the object directly from the memory section of the storage manager 4. For preventing that the user process 14 then due to some programming error may destroy data in the data base 2 by writing it is required that this access is done by calling routines in the storage manager 4. The storage manager 4 may then discover if the user process 14 tries to write in an object which it has not opened for updating. The calls to the storage manager 4 are performed in the form of so-called trap calls implying transition to a supervisor mode. The code executing in the supervisor mode has the possibility of writing into all parts of the memory of the computer, whereas the user process 14 has only access to its own private memory area 6.

The code of the storage manager 4 and the interface 12 thereof must be generic, i.e. created to suit all object types which shall be managed, also those which are not known in detail when designing the storage manager 4. For this reason an interface 12 is created such that the DMI operations may be able to manage all types of objects which will be stored in the data base 2, without any knowledge of the representation and semantics of data types. The DMI interface 12 therefore has a low level character making it unsuitable as a direct programming interface for application design.

The earlier above used concept type security is a concept within programming languages implying that the compiler may check that variables are used in a consequent way in the whole program. The programmer declares which type of data that shall be stored in variables. By the type definition there is determined representation and interpreting of the information which is stored in a variable. Variables, constants and parameters and return values to functions in a program are normally type declared.

The declaration makes it possible to the compiler to use the variable in an intended way. Use of an integer as a parameter to a function is e.g. prevented where there is expected a string of characters.

A more detailed description, partly by means of pseudo- code, will now be carried through of the methods used according to the invention for accessing and managing data in the data base 2. For a clarifying purpose the following convention will then be used: At each occurance,

1; indicates that comments will follow, 2; indicates that user code will follow, 3; indicates that generated code will follow, and 4; indicates that generic code in the storage manager will follow.

Read access. 1; Suppose that the object type Person is included in the data base. Accessing an object is performed in the following way: 2; Person: :openDirtyRead (<primary-key-value>) //Directed to a generated class method. (C++ syntax)

3; The class method calls the generic open-method parameters of the DMI interface: object type number and primary key value, of which the object type number is coded into the generated open-method.

4; The storage manager localizes a current object by means of a search index. Pointers, i.e. the physical memory address to the localized data base record are put into a table, and a check-summed index to the table is returned to the generated open-method. The data base record contains a reference to a class object which in turn includes i.a. a pointer to the DOA class designer. By means of this a DOA object of a real class is created in the memory area of the user process. In the DOA object the check-summed index to the address table is stored. The pointer to the DOA object is returned to the open-method.

3; The open-method returns the pointer to the user. 1; The DOA object may now act as an agent for the stored object. Access to the attribute size of shoe in the object is performed in the following way:

2; Size of shoe = PersonDOA->Size of shoe

3; The attribute size of shoe is represented in the DOA object by a method with the same name. The method calls the DMI operation for reading attribute values with the parameters offset and address table index.

4; The storage manager localizes the data base record by means of the address table and returns the value of the indicated attribute.

3; DOA returns the call to the client.

Updating. 1; Assume that there is the object type Person in the data base and that a transaction has started. Updating an object is performed in the following way: 2; Person: :openUpdate (<primary-key- value>,<transactionId>) //Directed to generated class method. (C++syntax) 3; The class method calls the generic open-method parameters of the DMI interface: transactionID, object type number and primary key value, of which the object type number is coded into the generic open-method.

4; The storage manager localizes the object in question by means of a search index. A copy of the data base record is created in the memory space of the storage manager. A poin¬ ter, i.e. a physical memory address to the copy is put into a table, and a check-summed index to the table is returned to the generated open-method. The data base record includes a reference to a class object which in turn includes i.a. a pointer to the DOA class designer. By means of this there is created a DOA object of a real class in the memory area of the user process. In the DOA object the check-summed index to the address table is stored. The pointer to the DOA object is returned to the open-method.

3; The open-method returns the pointer to the client. 1; The DOA object may now act as an agent for the stored object. Assignment of a value for the attribute size of shoe in the object is performed in the following way: 2; PersonDOA->Size of shoe_put(47)

3; The attribute size of shoe is represented in the DOA object by a method with the same name. The method calls the DMI operation for updating attribute values with the parameters attribute number and address table index.

4; The storage manager localizes the updating copy by means of the address table and assigns the value to the indicated attribute.

3; DOA returns the call to the user.

1; For making the updating persistent and visible to other processes the transaction in which it is included must be "committed". This is performed approximately as follows: 2; trRef->commit

4; The transaction manager prepares for commit by writing in logs etc. , and performing a 2PC protocol if the transaction is distributed on several processors. Thereafter copies and originals are interchanged so that updated objects become visible. The transaction manager executes post-commit triggers in the DOA for all objects included in the transaction.

3; The trigger method belongs to the DOA. 4; The transaction manager releases the locks and removes the DOA objects. Return to the client.

Instancing. 2; Person: :create(<primary-key-value>,<transactionId>) // Directed to the generated class method. (C++syntax) 3; The class method calls the generic open-method parameters of the DMI interface: transactionld, object type number and primary key value, of which the object type number is coded into the generated open-method.

4; The storage manager reserves the primary key value of the object. A data base record is created in the memory space of the storage manager, but it is not connected to a pointer, i.e. a physical memory address to the copy is put into a table and a check-summed index to the table is returned to the generated open-method. The data base record includes a reference to a class object which in turn includes i.a. a pointer to the DOA class designer. By means of this there is created a DOA object of a real class in the memory area of the user process. In the DOA object there is stored the check-summed index to the address table. The pointer to the DOA object is returned to the open-method.

3; The open-method returns the pointer to the client. 1; The DOA object may now act as an agent for the stored object. Assignment of a value for the attribute size of shoe in the object is performed in the following way:

2; PersonDOA->Size of shoe_put(47)

3; DOA returns the call to the user.

1; For making the updating persistent and visible to other processes the transaction in which it is included must be "committed". This is performed in the same way as has been described for updating object.

A description of support system functions will now follow.

With reference to Figure 3 the code for the agent objects is generated from an object type description 24 in a determined data definition language. A compiler 26 for this language also generates a description of the structure of the data record, which is used by the storage manager 4 for managing the data of the object. The data structure description and the DOA code are packed into a loading modul which may be loaded into the system. Below the above mentioned code generation will be described more in detail.

As has appeared from the above, stored obejcts are managed as a data record in the storage manager 4 and are represented by an agent object 16 towards the user. This presupposes that the storage manager 4 knows the structure of the object, i.e. its stored attributes and that the agent object may identify to the storage manager which attributes it will access. This is made possible by means of the data definition language with the compiler.

By means of the data definition language it is possible to write a formal specification of an object type. From this specification there is generated on the one hand a data structure description which may be loaded, arrow 28, into the storage manager 4, on the other hand the code for the agent object 16, arrow 30. In the generated code there is included a call to the DMI interface 12, where the attribute of the object is identified with attribute numbers. In the generated DOI interface 22 the same attribute is identified in plain language with the attribute name, that is used in the declaration.

When an attribute is declared in the data definition language its name and type is indicated. In the generated code the attribute appears as two functions, one for reading, and one for writing, with the same name as the declared attribute, said functions respectively return or accept values of the same type as the declared type of the attribute. In the data structure description loaded into the storage manager 4 the same attribute is represented by an attribute number and a size information corresponding to the storing space of the declared type.

The invention provides performance advantages, in particular in connection with read accesses and updatings relating to a smaller part of an object. A short time of response appears at opening and no re-copying to the data base is needed after an updating, but the object is all the time located in the data base. By making all write operations via the interface 12 to the storage manager 4 and not by letting application code write directly into the data base memory, protection is obtained against the application unintentionally destroying other objects by writing, than those accessed for the time being.

The solution also makes possible some extra functions which would have been difficult to realize in another way: - Triggers.

Since all writings into the data base is done through the interface 22 of the agent object 16, object types and attributes may be provided with triggers. The trigger is implemented by the DOI operation besides making a DMI call, i.e. a call via the interface 12, also executing the trigger code, which is a part of the agent object 16.

- MOSI interface.

For cooperation with a generic tool for user interfaces the objects are provided with an interface called MOSI

(Managed Object Support Interface) . This is an interface including parameters for access to attributes and execution of methods in the object, operated from a generic object managing agent. The methods in the MOSI interface comprise a mapping from external identities to internal and are generated by the compiler 26.

Claims

Claims.

1. A method for attaining data access to the data of a primary memory based data base, said data base having an operating system including a storage manager having a memory, and the data of said data base being organized as data entities containing attributes and methods, said method comprising opening a user process and providing a generic interface for said user process, accessing a data entity in the data base from said user process by the steps of creating in the user process an agent entity that con¬ tains a reference to the real data entity, and appears as if it were the real data entity, performing all accesses to the data of the data entity by reading directly, by means of said reference, in the memory of the storage manager, and performing read and write operations towards the attribu- tes of the data entity via said generic interface.

2. A method according to claim 1, comprising performing an opening operation for opening said data entity, including assigning to said user process a pointer to said agent entity, having an interface of the real data entity as decla- red in a data entity type description for said data entity.

3. A method according to claim 2, comprising creating said agent entity to form said reference as a pointer realized in a way enabling checking that the reference is valid.

4. A method according to any of the preceding claims, comprising the step of reaching a code for the methods of the data entity by means of a dynamic linking mechanism performed in connection with creating said agent entity, and admitting for said user process to open said data entity without need to know a class code of the data entity.

5. A method according to any of the preceding claims, comprising enabling for the agent entity to read the data of the data entity directly from the memory area of the storage manager.

6. A method according to any of the preceding claims, comprising calling said storage manager for causing tran- sition to a supervisor mode, in which the executed code has the possibility of writing in all parts of the memory of the processor, whereas the user process only has access to an own private memory area.

7. A method according to any of the preceding claims, comprising generating from a data entity type description of said data entity in a data definition language a code for said agent entity and a description of the structure of a data base record including said data entity, and using said description by said storage manager for managing the data of the data entity.

8. A method according to claim 7, comprising identifying to the storage manager by means of the agent entity the attributes desired to be accessed.

9. A method according to claim 7, comprising including in the generated code calls to the generic interface, in which the attributes of the data entity are identified with attribute numbers, and identifying in the generated interface of the agent entity the same attributes in plain language by means of the attribute name used in the data entity type description.

10. A method according to claim 9, comprising declaring an attribute in the data definition language by indicating its name and type, and including in the generated code the attribute as two functions, one for reading and one for writing, with the same name as the declared attribute, said functions returning respectively accepting values of the same type as the declared type of the attribute.

11. A method according to claim 10, comprising representing in the description of the structure of the data base record loaded into the storage manager, the same attribute by an attribute number and a size information corresponding to the storing space of the declared type.

12. A method according to any of the the preceding claims, wherein said data entities are objects in an object- oriented data system.