Hi Heikki,
I found something in the old ODMG 3.0 standard:
6.3.1.2 Object Deletion
In the Smalltalk binding, as in Smalltalk, there is no notion of
explicit deletion of objects. An object is removed from the database
during garbage collection if that object is not referenced by any other
persistent object. The delete() operation from interface 'Object' is not
supported.
-> So it seems that some kind of Garbage Collection was envisaged by the
standard, if only for Smalltalk. However, as I said before, I'm not
aware that this was ever implemented outside the SmallTalk community,
and I don't know SmallTalk well enough to tell how much GC might differ
from Java GC.
So while the term 'GC in databases' doesn't seem to be entirely new,
your approach may bring new ideas to the table, including a solid
theoretical foundation. Maybe it would even explain why it hasn't been
implemented in any major DBMS.
For example, POET Navajo supports ODMG 3 but apparently chose _not_ to
support GC (first page, last paragraph):
http://www.odbms.org/wp-content/uploads/2013/11/038.01-Jordan-An-Object-Database-for-Embedded-Environments-April-2000.pdf
Regards,
Tilmann
On 20.05.2016 19:55, Hei Virk wrote:
Hi everybody:
I will comment later more.
-I am just going to keep a presentation about the topic in my university
here in Finland for theorists and I am making those slides at a moment..
One social observation:
In my understanding the situation has been that people (me too) have not
been understood that that a modified object structure can always be
returned back into the database in a deterministic and meaningful way. - I
mean that the well defined result exists always for an operation. This is
because the modifications in Run-Time memory can be so arbitrary.
For this reason no one has been able to think the problem? Therefore the
method can not have been in any db standard either.
Regards,
Heikki
On Fri, May 20, 2016 at 7:49 PM, Tilmann Zäschke <zaesc...@gmx.de> wrote:
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
