chat channel
joafip users mailing list
forums
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.
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.
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.
