This essay does not describe an existing computer program, just one that should exist. This essay is about a suggested student project in Java programming. This essay gives a rough overview of how it might work. I have no source, object, specifications, file layouts or anything else useful to implementing this project. Everything I have prepared to help you is right here.
This project outline is not like the artificial, tidy little problems you are spoon-fed in school, when all the facts you need are included, nothing extraneous is mentioned, the answer is fully specified, along with hints to nudge you toward a single expected canonical solution. This project is much more like the real world of messy problems where it is up to you to fully the define the end point, or a series of ever more difficult versions of this project and research the information yourself to solve them.
Everything I have to say to help you with this project is written below. I am not prepared to help you implement it; or give you any additional materials. I have too many other projects of my own.
Though I am a programmer by profession, I don’t do people’s homework for them. That just robs them of an education.
You have my full permission to implement this project in any way you please and to keep all the profits from your endeavour.
Please do not email me about this project without reading the disclaimer above.A persistent object database lets you do two things:
How could you write a very simple one? Start by implementing the Hermit Crab variable length file class. Use ordinary serialization 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 (Persistent Object Databases) 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:
You might like to study a commercial POD before attempting to write your own. See Objectstore and Poet.
This page is posted
Optional Replicator mirror
Your face IP:[126.96.36.199]
You are visitor number|