How JOAFIP works

Object state is stored in data record using a heap file.

CRUD (Create Read Update Delete):

CUD (Create Update Delete) of CRUD :

It is maintained in memory informations associated to object read in file, it uses a map whose key is the read object identity key and data is the informations. Informations are: data record identifier, state at reading ...

All are done when saving. The save process visits the object graph from the root object, then check all readed objet. These visit make possible for each object to compare with state readed in file:
- Create: if it is a new object ( no state from file ), then it is saved in a its file data record.
- Update: if object state change then its associated data record in file will be updated. It also manages reference to other object change
- Delete: when an object is no more referenced by any other object then the data record associated to this object goes to garbage candidate pool or to destroy pool ( two case according of cycle problem )

R ( Read ) of CRUD

It is here where proxy are used to avoid wasting memory, do not check if enough memory but always create proxy to save memory.
The root object is first created in memory as a not loaded proxy.
Access to object is always done navigating from the root object calling object's method that return proxied objet.
Interception of object method call make proxy load object state from file.

Collections

Since collections are object instances of classes having primitive and/or reference field, then the same mechanism can be applied.
But some implementation do not follow the joafip conditions on classes ( because of proxy for lazy load ), and some implementation use serialization mechanism that joafip first release can not use. Because of this JOAFIP have its own collection implementation, but also because JOAFIP implementation is better to have efficient lazy load ( for example it is the case for HashMap and HashSet java native implementation - same thing for GNU Trove implementation ).
Since release 2.0.0 JOAFIP can invoke serialization method implemented in class, so it can persist native collection implementation, but it is not the best for a good lazy load management.

Example:

Below is described how object are persisted on file.

At data access session opening the root object is loaded from heap file.
The data access session manager has a getter to obtain the root object instance in memory.

It becomes possible to add objects referencing each other with one referenced by the root object container

After creating the object closing the data access session with save option will persist the object graph in heap file.
After this there is no more object in memory ( after JVM garbage collect ! )

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

just request for o1 from already loaded root object loads o1 transparently.

then, for example supress reference from o1 to o2 and add o5 be referenced by o3.
Adding o5 to o3 ( using o3.setXxx(o5) for example ) triggers getting o3 ( by o3=o1.getYyy for example ) , which will transparently load o3 into memory.
o4 and object it references will not be loaded in memory.

then save by closing data access session:

o1 data record is updated because o1 state changed
o3 data record is updated because o3 state changed
o5 is created in file
o2 data record in heap file will be free by a garbage collector

After this there is no more object in memory .

Where is some case of 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 to itself.