Persistence and Objects Group presentation given by

Barry Myles

Gary Stewart

Stephanie Dunsire

Introduction This presentation will give an in-depth

view of persistence When coupling the programming power of an object-oriented

language like Java or C++ with the data storage and manipulation mechanism’s of a relational database, difficulties arise! Due to different characteristics when handling data

Programming Languages work with transient data, where as Relational DB’s tend to work more with Pesistant data

Also due to differing modelling paradigms A Relation Model cannot map directly to an OO Model

What is Persistence Persistence has different meanings

With respect to a single piece of Data “With respect to a piece of data it means the length of time for

which that datum exists.” [Ref: Object Database and ODMG approach - Richard Cooper]

With Respect to an Information system "A persistent programming language (PPL) is a programming language that

includes a persistent memory area (e.g., a heap of objects) that outlives the execution of any individual program." [Ref: Working with Persistent Objects - J. Eliot B. Moss]

Types of Persistence How do program’s write of data to

secondary storage The Three types of persistence are

Session Persistence File Persistence Orthogonal Persistence

Types of Persistence Session persistence - allows the state of a program to be

resumed from a snapshot of the system. Used where the entire state must be restored and/or where the

workspace size is small Examples:

Windows Hibernation mode Smalltalk implementations Machine Emulators

Able to take the state of the machine they are emulating

Types of Persistence Session Persistence(contd.) Problems:

Not designed for multiple users modifying the same system.

User has no control over what is and is not saved.

For its inability to allow concurrent users to access the same workspace schema this system is not suitable for database systems.

Types of Persistence File Persistence

The widest used format for storing data. Traditional way of making programming

languages persistent. Extracts the data from the program and then

writes it of to Secondary Storage. This will normally have to be converted to be placed back in the

program as data

Types of Persistence File Persistence (contd..) Problems:

Conversion of data to and from the application can be expensive both on processor and designer time

Open access to the file may lead to other programs corrupting it although access to a file in this manner is not always bad practice,

it can be useful Since there are multiple models for the data in files, one for

internal data and another for files then this removes the simplicity of a single model view.

Types of Persistence Orthogonal Persistence

Concerned with storing the data in the same structure on the disk as it had in memory

If a class is marked as persistent the program will also make all the data in the lower classes persistent to. This maintains referential integrity.

Allows any memory data to be stored without transformation

The same logical data structure exists in main memory as it does on hard disk

Allows any data value to be made persistent or transient irrelevant of type

Types of Persistence Orthogonal Persistence (contd.)

Only areas of either the code or data that need to be addressed will be brought into memory, the rest will remain on disk until required.

The data model of the database can represent the class structure.

The database itself represents the class hierarchy. This results in the the persistence being a single

representation of the data.

Distinguishing Transient and Persistent Data Implementation varies by a large degree in the

different OODBMSs. The two main criteria are:

How little effort it takes for the programmer to make objects persistent

Efficiency of the storage of data in the system

A benefit to one of these criteria may result in a loss of performance/decreasing functionality of the other.

Marking Persistence An object can be marked as persistent in one of

two ways: Explicitly declared as persistence by the programmer or

programming language Is reachable by another persistent object, therefore must

persist otherwise it will lead to a dangling reference

All objects that are not part of the set above are transient

Not all languages support persistence by reachability, these either force the programmer to check all references or allow dangling references

Marking Persistence—Explicitly Multiple methods of marking persistence used

Some systems may allow more than one method.

Seven main methods used Named Root Objects Persistent Classes Persistence Declared at Object Creation Persistent Root Class Persistent Shadow Classes Persistence By Explicit Storage System–Provided Persistent Roots

Persistent Shadow Classes

Automatically creates a persistent class for all classes that exist

User can then use the persistent class to create an instance of the class or use the transient class

Once initialised as one type cannot be changed to the other (though it should be possible to copy the object across)

Ensures that all classes in the language are persistent capable

Persistence By Explicit Storage This provides a method to call an object to be

stored at any time, hence making it persistent Similar to file persistence but should be orthogonal unlike

file persistence Has the run time cost of copying the memory requested into

the persistent store One of the most flexible systems, should allow all objects to

be made persistence Obviously supports the 'upgrading' of object into persistent

objects

System–Provided Persistent Roots This provides a mechanism for adding objects to a

persistent store The persistent store has some method allowing the user to

add an object to it The object, by being in this store, is persistent The store should allow all object types to be added hence all

objects can be made persistent at run-time and 'upgraded' from transient objects

The System-Provided Persistent Roots should be globally available

ODMG uses this for it's Java and Smalltalk implementation.

Persistence By Reachability This means that if an object is persistent all objects

that are referred to by that object must also be made persistent or references would become invalid

Explicit persistent objects therefore dictate what is made persistent from them, however a cascading effect may happen

This should be entirely handled by the system but may make the programmer confirm things to be persistent

Persistence By Reachability Persistence by reachability provides:

Referential integrity to the system by insuring object that are referred to by a persistent object are retained

A reduction of workload by the programmer as they no longer have to explicitly state what objects are to be made persistent

It may, however, store unwanted data that will increase the size of the database Programmers might be able to denote fields in objects

that are never to be made persistent (transient keyword in Java)

Storing Code and Data is important as databases can hold complex data.

The Figure 1 shows file systems, code is shown as ovals, while data is shown as rectangles:

Storing Code and Data

Figure 1

System (a) in figure 1 is an unprotected file system however it has a flexible environment in which code and data can be freely mixed.

System (b) in figure 1 is a traditional DBMS that controls part of the file system, which it uses to store and protect the data. Application code remains outside the control of the DBMS.

System (c) in figure 1 is an orthogonally persistent language, which allows code to be protected as well and for data and code to be freely mixed.

System (d) in figure 1 is an OODBMS file system that provides a class structure in which the mixture of code and data is controlled.

Systems which exclude the program code from the structure of the database, will often fall into disuse as they make the creation and maintenance of the applications exceptionally costly and error-prone.

Removing DataAn important facility a database must provide is a method of removing unwanted data, there are various methods of removing data which depends on the system:

Explicit Deletion of Data – Systems can allow explicit deletion of objects and classes. Some systems allow this as it is believed that the programmer can achieve the most efficient storage of data. This method can avoid integrity violations for example by using C++ an operation called a destructor can be used, thus it can be used to explicitly remove data without causing deletion violation.

Garbage Collection – Systems can also allow an automatic method of removing data called garbage collection, a popular use of garbage collection is in a OODBMS which uses persistence through reachability.

Types of Garbage Collection Mark-and-Sweep

This involves two stages: Mark - This starts at the persistent root objects and marks everything referred to by the roots as required data, and then recursively marking further objects referred to by already marked objects until all objects are marked. Stage two Sweep – removes unmarked data so the space is freed and returned to the free pool for future reallocation. The problem with the mark-and-sweep method of garbage collection is that it has a tendency to fragment memory.

Stop-and-Copy This method collects garbage and de-fragments memory, this

method involves the memory being divided into two regions an active region and an inactive region. The stop aspect of the method starts when the memory in the active region is exhausted, the copy aspect of the method copies all of the live objects from the active region to the inactive region. The final step is to switch the active and inactive regions, as this method only copies the live objects any objects left over are garbage and are deleted. The problem with this method is the cost of doubling the size of the heap (i.e. active and inactive).

Reference Counting This method involves every object keeping a count of all

references made to it, thus every time a new reference is made this total is incremented and every time a reference is removed the total is decremented. If the total is zero the object is unreachable and so is garbage and can be removed. . The two main problems of this method: the counts and maintaining them can take up space and there is no guarantee that all unreachable objects will have a reference count of zero.

Mark-and-Compact This method again consists of two phases: the first phase mark

this starts at the persistent root objects it marks everything referred to by the roots as required data, and then recursively marking further objects referred to by already marked objects. The second phase is called the compaction phase this collects anything that remains as garbage and compacts the memory by moving all the live objects into continuous memory locations. This method eliminates fragmentation and does not incur the additional costs of additional space.

Example Garbage Collection An example of Garbage Collection is a course being cancelled at

Napier due to this all students on this course can be relocated on other courses or leave (in this scenario we will ignore the students that leave), the course attribute of the student objects will be changed to their new courses. Once all objects representing the members of the course are updated there will be no references left from the student objects to the old course object thus it can be removed from the object holding the set of courses and as there will be no existing references to the object it will become unusable data Figure 2 shows an object graph with garbage and non-garbage aspects:

Figure 2

References ODMG 2.0: A Standard for Object Storage by Doug Barry

Component Strategies (July 1998)http://www.odmg.org/library/readingroom/Article%20-

%20Components%20Strategies%20-%20July98.html Garbage Collection In Java, Vern Martin, December 2, 1997:http://trident.mcs.kent.edu/~vmartin/proj/proj.html A presentation on mark-and-compacthttp://cselab.snu.ac.kr/project/ipctv/javagc/

gcoverview/sld010.htm Databases From Relational to Object Oriented Systems by Claude

Delobel (1991)