Deletion semantics in KMF
Closed this issue · 5 comments
I wonder how the deletion of an element is managed by KMF. For me, a deleted element, and all its contained elements (i.e. its containment tree) should be available for garbage collecting i.e., no more reference (composite, as well as "normal" references) should point to these elements.
How is that managed in KMF?
Hi,
There are two methods for removing an element from the model.
container.removeContained(elem) removes the element from the collection of contained in the container.
This method just removes the element from the collection and also resets the opposite references.
This is the usual remove semantic.
The delete() method available on model elements in KMF currently deletes all the contained sub-tree of objects.
It does not remove the element from its container collection (which should be done) and does not care about the existing references.
As a conclusion, we propose to let the semantic of the remove method as is; and complete the behavior of the delete so that it:
- actually removes the element from its container
- deletes all its contained the sub-tree
- resets all the references pointing to this element and any of the contained sub-tree.
NB: If the two first points can be done easily and in an effective way, the last will be very time consuming since we'll have to go through all references in the model.
Would this be aligned with your vision ?
I would like a delete operator (in addition or replacement of existing ones) whose semantics is aligned with the usual semantics of model serializers (even though I am not quite sure about the serialization semantics of KMF regarding serialization): non-contained elements are discarded (or makes the whole serialization crashes, it depends) and should be garbage collected not keep these gost/transient/useless element in memory.
In other words, a delete operator that maintains model consistency (w.r.t. serialization). Even though I agree with you, it might be useful (for performance reasons, mostly) to be able to maintain models in memory that are not consistent.
I guess it should be possible to have special kind of Observer collections for simple references that, when an element is added into them, observe this element and get notified when this element is removed. This would avoid browsing the whole model...
I agree the performance issue is critical in KMF, but I would prefer an automated solution to my problem (which I believe is quite common) rather than hand-coding something, which is likely to be as counter-performant (if not more) as the solution you would implement, and which is also likely to be less consistent.
As for the .equals issue, we should probably go for a delete (as is, with the update you propose regarding the container) and a deepDelete (which we could call gc, since the goal is to make the element available for garbage collect, even though we should probably not force a System.gc() and let the JVM decide). The choice of delete and gc should be let to the user, whether he prefers performance or consistency, depending on his use case.
And again, regarding your last bullet point, I am pretty sure we do not need to browse the whole model, since it should be possible for an element to be aware of which elements/references are actually pointing to it (modulo a slight memory increase)
it has been integrated in the delete method, which now take care to cleanup pending references