HI Heikki, > On May 20, 2016, at 10:55 AM, Hei Virk <hvirk...@gmail.com> 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.
The way JDO works is that you can retrieve complex object graphs from the datastore in a single operation (or multiple operations). Once the object graphs are in memory, the relationship between the objects in memory and the persistent representation (objects in an ODBMS or rows in an RDBMS) is managed by the PersistenceManager. If a user makes a change to any of the objects in the graph, the change is automatically detected and when changes are flushed to the datastore (either explicitly or at transaction commit), the changes are made persistent. Many datastores require that changes be applied in a specific order so as to avoid introducing inconsistencies (foreign key constraints). The implementation is required to understand the constraints and avoid the inconsistencies. Reachability of all objects might be defined as a constraint in an object datastore. The exact mechanism for making changes is decided by the implementation. Garbage collection of persistent objects could be done as part of the flush/commit operation, depending on how the implementation works and which datastore is used. Leaving unreachable objects in the datastore might be considered an inconsistency that the implementation should avoid. Regards, Craig > > 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 >>>> >>> >>> >> Craig L Russell Architect craig.russ...@oracle.com P.S. A good JDO? O, Gasp!
