Hi,
As far as I can tell garbage collection is an established concept in
object databases, I think the oldest one that support it is
GemStone/Smalltalk
(https://downloads.gemtalksystems.com/docs/GemStone64/3.3.x/GS64-ReleaseNotes-3.3/GS64-ReleaseNotes-3.3.htm).
However, I'm not aware of any major Java-ODBMS that supports it.
Some comments:
- As Andy describes, it could be supported via a property of the PM.
However, there may be scenarios when 'embed' and 'makePersistent' are
regularily use in the same transaction, so if the feature would be
widely used, it may make sense to have a dedicated 'embed' method.
- as far as I am aware, the JVM has moved away from reference counting.
The situation in an DBMS may be different to an in-memory JVM, but if an
ODBMS implements GC, it may be worth checking out other garbage
collection techniques.
- It seams that enabling garbage collection via reference counting will
have quite some impact on performance, because objects get bigger
(little impact) and because it requires updating of additional objects
in the database to update the reference counters (the counters also need
updating when _adding_ references). I would therefore argue that support
for garbage collection should be determined at database creation time,
or as a flag when defining database schema. This would allow avoiding
the GC overhead when GC is not required.
Cheers,
Tilmann
On 13.05.2016 15:49, Andy Jefferson wrote:
Hi,
-I have invented a new declarative method to update object databases and I
would like to introduce that method you.
My question is:
Should the functionality of this method included in some future versions of
JDO (and perhaps some other definitions/systems under Apache)?
Also I am interested about your comments/critique on the method.
The name of the method is "embed" and it resembles the command
pm.makePersistent(s);
used in JDO-enabled applications. The embed method is called in equivalent
way,
db.embed(s);
but it has a larger functionality than the current makePersistent method.
My opinion/comments, others may have other thoughts :
For something to be part of JDO, it needs to be widely applicable across other datastores, not just
for one "type" of datastore. If it is only implementable on 1 type of datastore then
standardising it would be "premature"; that isn't to say that it isn't applicable to
others.
From what I read of your method it is basically a makePersistent (attach) but with
"deleteOrphans" enabled; i.e it addresses the object graph defined by the input object,
and additionally deletes orphaned objects. Firstly it is entirely reasonable to be able to do that
right now in terms of API (**assuming the JDO implementation provided the internals**) since the
user can call pm.makePersistent and can have set properties on the PersistenceManager just before
that call (pm.setProperty(...), so can set some "deleteOrphans" flag). From that I can
conclude that I don't think there would be any change to the API needed to provide your mode of
operation.
Deleting orphans may vary dependent on the precise relation, hence why JDO
allows metadata on each field, so some orphans can be deleted and others not.
Clearly a JDO implementation would need to provide a "deleteOrphans" mode
internally to support this.
Detail of how your method works in an object database, whilst interesting, is
not of relevance to the JDO spec question, since the spec doesn't define HOW an
implementation implements features
Regards
