Hello Hei,
sorry, I posted my answer first only to the dev list, I'm not sure you
are on it.
So here it is again, with some updates:
Hi,
I haven't read the whole post in detail, but I understand the main idea
is garbage collection in databases. This reminds me of similar concepts
in osome object databases, such as 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. One problem are reference cycles, I haven't read
the full blogpost how this is solved.
- 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.
- We would need to be able to identify root objects which should not be
garbage collected. This could also be done via a flag on the schema,
i.e. every object of a class that has no reference counters is
automatically a root object.
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
