feedback / send your comments
mail to luc peuvrier
chat channel
joafip users mailing list


En Français

How JOAFIP works

Object state is stored in data record using a heap file.(key/value store)

How object graph can be store in a key/value store

The persistence management use informations associated to object read from file.
This is done using a map in meory where for each entry the key is the system identity of object and the value is the persistence informations. 
The main informations associated to object are data record identifier in heap file and object state at reading.

CRUD (Create Read Update Delete):

CUD (Create Update Delete) of CRUD :

Create, update, delete, is done when saving in file. The saving process visits the objects graph from the root object. 

At visit, for each object to compare with state read in file:
- Create: if it is a new object ( no state on file ), then it is saved in a new data record in file.
- Update: if object state changed then its data record associated  in file will be updated. This include object referenced changes.
- Delete: when an object is no more referenced by any other object, so then the data record associated to this object goes to the set of "candidate to be garbage"  or to the set of  "to be destroyed" ( two case according to possibles cycle in object graph)

R ( Read ) of CRUD 

It is here where the proxy are used to avoid wasting memory, do not check if enough memory, but always creating a proxy to save memory because it not make reference other objets until it is accessed.
The root object is first created in memory.
Access to object is always done by navigating from the object root, by calling its methods that will return proxied objet.
The interception of object method call make proxy loads its state from file.


Since  instance of collections is an object graph, the same mechanism is applied.
But some implementation do not follow the joafip conditions on classes. These conditions are imposed because of proxy usage.

Because of these conditions, JOAFIP have its own collection implementation.

But also because the JOAFIP implementation is better to have an efficient lazy load ( for example, this is the case for the HashMap and the HashSet java native implementation - same thing for the GNU Trove implementation ).

Since release 2.0.0, JOAFIP can invoke the serialization methods implemented in class, so it can persist the native collection implementation, but it is not the best for a good lazy load management.


Below is described how object are persisted on file.

At the data access session opening, the root object is loaded from the heap file. The root object role is to reference all other persisted object.
The manager of the data access session has two methods to manage the persisted objects referenced by the root objet.


To be able to persist a graph of objets, it must be referenced by the root object.

Closing the data access session, with save option, this make persist the graph of object starting from root object.
After this, releasing (unreferencing) the objects, there is no more objects in memory ( after JVM garbage collect ! )

To access again to objects, just open a session that loads the root object only.

The request for object o1 from the already loaded root object will make an automatic load of object o1.


An example of operations on objets is showed below.

o1 no more referencing o2:
new object o5 referenced by the object o3:
o3=o1.getXXX(); o3.setXXX(o5);

Proxy do an automatic loading of the object state from file since object's methods are called.

then save by closing data access session:

After this there is no more object are in memory .

There is case where references between object do not change, but primitive field modification make update the data record in heap file.

Garbage candidate:

Starting with object graph saved in file

then read the root object

And make the root object no more reference the object o1 ( for example, something like rootObject.setO1(null) )

Then save and close session:
the object o1 became a candidate to garbage. The garbage collector has to check that o1 ( in file ) is not attached to the root object by a referencing path from root object.


feedback / send your comments
mail to luc peuvrier
chat channel
joafip users mailing list

© 2007-2011, joafip