Persistent Object Database

• You are here :
• home
• Java Glossary
• Student Projects
• Persistent Object Database
•  

©1996-2012 Roedy Green, Canadian Mind Products

Please do not email me about this project without reading the disclaimer above.

1. Code as if you had unlimited amounts of virtual RAM (Random Access Memory) for your objects.
2. Shutdown and restart a program without losing your objects.

How could you write a very simple one? Start by implementing the Hermit Crab variable length file class. Use ordinary serialisation to save and restore objects. You can retrieve objects from the hermit crab file by serial number.

Basically you are simulating a segmented virtual memory system with an LRU (Least Recently Used) cache of objects. You need an array indexed by object number. With that array you can find out if the object is currently in RAM, and if so where in RAM it is. If it is not in RAM, you can use the object number to retrieve it. You also have to keep track if each RAM-based object is clean or dirty. Dirty means it has been changed, and eventually the disk copy will have to be updated. The simplest way to implement an LRU is to maintain a chain. Every time an object is touched, you move it to the head of the chain. The object on the tail end of the chain is then the least recently used.

Ideally you would code your application that used the POD as if the POD were not there. Some commercial PODs automatically insert code in your application to help give that illusion. The trickiest part of this project involves techniques to make the POD as transparent as possible. You might want to study some commercial PODs to get some ideas on how to handle this.

Let’s look at some of the problems:

• If you get too many objects in RAM, you have to get rid of some, writing them to disk if dirty. There must be no pointers to those objects before they are released. The only pointers permitted to these persisted objects are object serial number style pointers, which will still work when the object is no longer in RAM. You peel them off from the end of the LRU chain.
• If you put code in a getXXX method to ensure an object is RAM-resident, you still need at least the shell of an object pre-existent.
• If you have grab and release methods for each object, you must deal with the problem of multiple nested grabs for the same object, and for failure to have a release for every grab. In a way you are back the bad old days of C++ manual memory allocation.
• You might want to get clever and have an automatic release done when a module exits for all the grabs it did. That requires tweaking the stack, which is JVM (Java Virtual Machine) dependent.
• If the system crashes, you will lose everything. For a commercial system, you need transactions that are guaranteed to be applied in toto, or not at all, even if the system crashes.

You might like to study a commercial POD before attempting to write your own. See Objectstore and Poet.

	You can get the freshest copy of this page from:	or possibly from your local J: drive (Java virtual drive/mindprod.com website mirror)
	http://mindprod.com/project/pod.html	J:\mindprod\project\pod.html
	Please email your feedback for publication, letters to the editor, errors, omissions, typos, formatting errors, ambiguities, unclear wording, broken/redirected link reports, suggestions to improve this page or comments to Roedy Green : If you want your message kept confidential, not considered for posting, please explicitly specify that.
	Canadian Mind Products
	mindprod.com IP:[65.110.21.43]
view Blog	Your face IP:[38.107.179.210]
Feedback	You are visitor number 7,175.