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)
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.
of collections is an object graph, the same mechanism is
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.
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
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.
Proxy do an automatic loading of the object state from file since object's methods are called.
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 joafip garbage collector
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.
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.