WO2001071492A1

WO2001071492A1 - Method and system for data management in an object-oriented system

Info

Publication number: WO2001071492A1
Application number: PCT/FI2000/000228
Authority: WO
Inventors: Shen Jianjun
Original assignee: Net Magic T:Mi
Priority date: 2000-03-20
Filing date: 2000-03-20
Publication date: 2001-09-27
Also published as: AU3560000A

Abstract

The invention is concerned with a method for saving and loading persistent objects on a persistent storage in a data processing system, each persistent object consists of structured data and methods for accessing data in said object. The method is mainly characterized in that one or more path codes are defined for each method. When a method is invoked against desired data of a persistent object, information of what data of the persistent object is involved in said method is generated by means of the path code(s) for that method. Said involved data is then loaded from a data source containing the data, and the involved data of the persistent object is accessed with the invoked method. The invention is also concerned with a data processing system in which the method is used.

Description

METHOD AND SYSTEM FOR DATA MANAGEMENT IN AN OBJECT- ORIENTED SYSTEM

TECHNICAL FIELD

The invention is concerned with a method and system for data management, especially for saving and loading objects in an object-oriented programming environment

BACKGROUND ART

Object-oriented applications are operational computer programs in which data and routines are organized together into encapsulated units referred to as objects In these applications, classified data is structured in form of objects that consist of attributes and methods Thus, an object "knows" what operations can be performed on its data

The attributes might be associated with a given person and the methods might be associated with one or more of these attributes For e g in a data base listing people, the attributes might consist of for example the name, the social security number and the profession The- methods of the object are functional capabilities associated with an object, such as get data, modify data, save or restore its state etc A prior art approach is to save an object on persistent storage using object persistence The state data for several objects is being stored on the same persistent storage For each object, the state data is stored as a single stream of data, which contains the values for all of the object attributes

The existing object in the memory of a computer is called in-memory object A persistent object is an object whose attribute (state) data is kept in a persistent storage and can therefore be restored to its latest state if the in-memory object (is lost (e.g. such as when the server terminates and restarts). Persistent data objects tend to be large grained (e.g. containing a large number of attributes and instance data). Object based persistence mechanisms in the prior art normally save or restore the entire object state to or from external storage at one time. When large grained persistent objects are saved or restored, this can be very costly from a performance viewpoint. Performance issues arise when the entire object is saved or restored. In order to lessen the effect of these performance issues, applications are structured to minimize the number of times, the object state is saved and restored. This creates data integrity problems related to the object's state. For example, In a system management environment, there might be a large number of user objects that represent all of the users in a particular distributed domain. When an access is invoked in such an environment, an application is required to display a list of these user objects (e.g. potentially hundreds or thousands) to a system administrator, -along with the name of each user. From that list, the system administrator selects a small number of user objects to interact with. If the entire state of each Of the hundreds or thousands of user objects must be restored when one object is reactivated, it results in performance problem where a tremendous -amount of4ata that will not-be-used is restored.

Users are introduced by attempts to alleviate the performance problems when using traditional prior art object based persistence mechanisms. The current state of an object is only written to the external storage when requested by an application or by some internal event within the object itself. This is not normally done whenever the state of the object changes, but it is usually done only after some very significant update to the object or when the object environment is going down cleanly, and the objects are asked to save themselves.

Attempts have been made for improving the performance and enhancing the data integrity of persistent objects in distributed object-oriented environments. In US-patent 5,870,742, there is presented a method an apparatus for enabling persistent attributes in an object oriented environment, which maintains persistent values for individual attributes. In this invention a copy of the encoded attribute and its type code is stored in memory in addition to the copy that exist in the external storage. Performance is enhanced during the object restoration process by restoring only the attribute values currently needed instead of the entire object. Type code information for the individual attributes is stored in the external storage so that the attributes could be accessed. The attributes can be individually accessed only in accordance with the pre-defined type code information for a given attribute.

The object of the invention is to develop a jnethod with a better and more flexible performance to keep persistent objects in data processing systems.

SUMMARY OF THE INVENTION

In the method of the invention for saving and loading persistent objects on a persistent storage in a data processing system, each persistent object consists of structured data and methods for accessing data in said object. The method is mainly characterized in that one or more path codes are defined for each method. When a method is invoked against desired data of a persistent object, information of what data of the persistent object is involved in said method is generated by means of the path code(s) for that method. Said involved data is then loaded from a data source containing the data, and the involved data of the persistent object is accessed with the invoked method.

The data processing system of the invention for accessing persistent objects comprising information on persistent storage has one or more user terminals for accessing the objects, a server that manages the objects, and a storage of stored persistent objects. The system is mainly characterized in that the server has one or more path codes defined for each method, that the user terminals have means for invoking a method against data of a persistent object, and in that the server has means for generating the information of data involved in said method by means of the path code(s) for that method.

The means for generating the information of data involved in said method by means of the path code(s) for that method is advantageously an object controller.

The structured data of the objects might be in form of a hierarchic structure of attributes_^ the attributes in each layer of the hierarchic structure defining sub- objects for lower level attributes and the path code(s) then defines the path all the way to an individual attribute, to a sub-object or to an object. The information generated by the object controller is advantageously in form of a list of meta- information of involved attributes by means of which the involved attributes can be fetched from and brought back to the persistent storage.

A method might consist of methods such as to get data, modify data, save or restore its state etc. Thus depending on the method, the accessed data is modified or just viewed. If it is not modified there is no need to store the accessed data but if it is modified in some way, the -accessed data is stored in said persistent storage after finishing the method. A copy of the accessed data can be stored in the memory of the server or a secondary storage.

In the ahove mentioned prior art patent, the attributes are stored in the persistent storage as multiple independent entities together with a type code by means of which the attribute can be individually accessed. An attribute can be accessed without having to fetch the entire object. In this invention, there is no need to store any type codes in persistent storage as in the prior art patent, wherein every attribute of the object needs to associate with a type code. If there is one thousand records or correspondingly 1000 object and every objects have 100 attributes, actually in reality, there would be often more than 1000 records and every object has more than 100 attributes, then there would be extra 1000x100 = 100000 typescodes need to be stored. This occupy storage place and even worse, because typecode need to be encoded and decoded, it consumes more computational power and speed turns slow. In the method of this invention, such power consumption and type code storage is avoided.

FIGURES

Figure 1 shows a normal way to save an object state on persistent storage

Figure 2 shows an interaction diagram for a prior art method for accessing a persistent object attπbute

Figure 3 shows the programming environment of the invention to load and save an objec state Figure 4 shows an interaction diagram for the invention approach of figure 3 for accessing a persistent object attribute

Figure 5 shows an example of a path code

DETAILED DESCRIPTION

In figure 1 there is shown a normal way to save an object state on persistent storage. An object 1 is saved in a memory containing attributes A and methods 5 -10. The attribute set A consist of e.g. A1 (the name), A2 (the street address) and A3 (the city). Object 1 has methods 5 -10, with which each attribute A1 - A3 can be accessed and activated in a manner well known in the art. The state data for several objects 1 , 2 and 3 is stored on a persistent storage 11. In figure 1 , the state data for objects 1 ,2 and 3 is stored for each object as a single stream of data, which contains the values for all of the object attributes. When a client invoke a save method or another method, the- server fetches the whole object state with all its attributes. In figure 2 an interaction diagram is shown for a prior art method for accessing a persistent object attribute. When a client invokes the method getName(1 ) on object 1 as shown in step 12, the server creates an in-stance for object 1 in step 13. Then the server fetches the whole state of the object with all its attributes from the persistent storage to the in-memory as shown in steps 14 and 15. The data for the name attribute is extracted from the in memory object in step 16 and the server then passes the requested information back to the client as shown in step 17. The client only needed the name, but not the street or the city, but still the server had to fetch all these .attributes, too. In a real application the number of attributes is high, not only three as in this example. To fetch all the state attributes of an object in order to check one or a few attributes is not economic.

Figure 3, presents the approach of the invention as a component structure. The objects are stored as a data.source on a persistent -storage 11 ' e.g. as in figure 1.

In the invention, the data of an bject can be structured in different ways. In the simplest lorm it consists of individual attributes only. The invention is, however, intended for more complex structures of data. Thus, the structured data of an objects can be in form of a hierarchic structure of attributes, the attributes in each layer of the hierarchic structure defining sub-objects for lower level attributes.. An example of such a structure appears in figure 5, in which data of an object is structured in a four-level structure. The object in figure 5 consists of -an account A1-, that -contains the attributes A11 -A14 being the string name A11 , int i A12, double balance A13 and Contact contact A14. The attribute A14 is a sub-object for the attributes Address address A141 and email A142. Attribute 141 furhter is a sub-object for the attributes streetl A1411 , street2 A1412, zip A1413, city A1414 and country A14 5. The objects might also extend to other objects.

The methods of the object are functional capabilities associated with an object, such as get data, modify data, save or restore its state. A method can be associated with one certain attribute or several attributes, a sub-object or even an object.

In one embodiment of the invention, one or more path codes are defined for each method in a way presented in figure 5. In figure 5, it is assumed that a method in question is associated with attribute A1412. The path code for this method then defines the path A1 - A1412, presented with a dotted line.

Depending on which embodiment of the invention is-used, the path code(s) might be especially defined for the method, or a default path code might be used. A path code might also be defined by programming pattern.

In figure 3, it is now assumed that a client has invoked a method (step 1 ) against some attribute and that an instance 23 for the object in question has been created. The server 20 then has to fetch one or more path codes (step 2) for that method from e.g. a property file-21. The path code an -alternatively be generated by programming pattern. The path code is sent to an object controller 22 so that the object controller by means of the^ath .code(s) -could generate information of what data is involved in the invoked method. This information can e.g. be sent in step 4 as a list -of meta-information of involve -attributes. The involved attributes can now be loaded in step 5 from a data source in a storage 11. If the accessed data was modified with the invoked method, the new object should be stored in step 6. Optionally, a copy of the new object can be stored in memory or a secondary storage (not illustrated).

Figure 4 shows an interaction diagram for the method of the invention for accessing a persistent object attribute. A client invokes the method getName(5) on object 1 as -shown in step 30. This causes the server to get a pre-defined path code associated with this method from e.g. a property file as shown in step 31. The code is sent to an object controller in step 32 to generate information of involved data (in this case only one attπbute ) associated with the method to be sent to the server in step 33. The involved attributes are then loaded from the persistent storage in step 34 and sent to the object in step 35 from which they are fetched by the server in step 36. The attributes associated with the invoked method are then-returned to the client in- step.37.

Claims

1. Method for saving and loading persistent objects to and from a data source on a persistent storage in a data processing system, each persistent object consisting of structured data and methods for accessing data in said object, the method comprising a) defining one or more path codes for each method, b) invoking a method against desired data of a persistent object, c) generating information of what data of the -persistent object is involved in said method by means of the path code(s) for that method, d) loading said involved data from a data source containing the data, e) accessing the involved data of the persistent object with the invoked method.

2. Method of claim ^ cha racte ri zed in that the structured data of an objects is in form of a hierarchic structure of attributes, the attributes in each layer of the hierarchic structure defining sub-objects for lower level attributes.

3. Method of claim 2, charaoteriz-ed in that one or more of the objects or sub-objects extend to other objects.

4. Method of any of claims 1 -3, characterized in that the path code(s) defined might be a default path code and/or ihe-path code(s) might be defined by programming pattern.

5. Method of claim 2 or 3, characterized in that the path code(s) defines the path to an object, to a sub-object or to an individual attribute.

6. Method of any of claims 1 -5, characterized in that a method consists of methods to get data, modify data, save or restore its state etc.

7. Method of any of claims 1 -6, characterized in that the information of what data of the persistent object is involved in said method is generated by a object controller by means of the path code for that method.

5 8. Method of claim 7, characterized in that the information is generated in form of a list of meta-information of attributes by the object controller.

9. Method of any of claims 1 -8, characterized in that if in step e), the accessed data is modified, it is stored in said-persistent storage after finishing 0 the method.

10. Method of claim 9, characterized in that a copy of the accessed data is stored in the memory of the server or a secondary storage.

5 11. Data processing system for accessing persistent objects comprising information on persistent storage,, comprising one or more user terminals for accessing the objects, a server that manages the objects, a storage -with of stored persistent objects, d c i a r a c t e r i z e d in that a) the server has one or more path codes defined for each method, b) the user terminals have means for invoking a method against data of a persistent object, c) the server have means for generating the information of data involved in 5 said method by means of the path code(s) for that method.

12. Data processing system of claim 11, characterized in that the means for generating the information of data involved in said method by means of the path code(s)-for that method- is-anobjectαantroiler. 0