[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: garbage collection?


The more interesting question seems to me: How to keep track of all
references of a database object ? E.g. ozone has no chance to find out
a simple assignment such as 'dbobject1.member = dbobject2',
which means that dbobject1 references dbobject2. So, we would need
to count references by hand, i.e. one method to set a reference and
one method to remove a reference. But that seems to have no advantages
compared to explicite deletion of objects.

Best Regards,
Gerd

> On Wednesday, April 11, 2001, at 03:50 AM, Falko Braeutigam wrote:
> 
> > On Tue, 10 Apr 2001, Reason wrote:
> >> You can make very complex interrelationships between objects, you just 
> >> have
> >> to make the low-level code that manages the objects a little different.
> >> Persistent Ozone objects hang around until you database().destroy() 
> >> them.
> >> So, to take a trivial example, if you have multiple objects of class X 
> >> that
> >> contain references to a single object of class Y, you need to change 
> >> the
> >> behavior of X.removeReferenceToY() (or vice versa) such that the Y 
> >> object is
> >> destroy()ed if it doesn't have any references left.
> >>
> >> Removing references on deletion is pretty easy -- just use the 
> >> onDelete()
> >> method liberally.
> >>
> >> [I can't see any reason as to why you couldn't start up an object 
> >> removal
> >> thread in a persistant object in the database server as well, but that 
> >> may
> >> be costly compared to just deleting where appropriate in you low-level
> >> code].
> >>
> >> Have a look at www.twilightminds.com/datafull.html for an example of 
> >> complex
> >> interrelationships (based on simple rules and three classes) handled 
> >> in an
> >> Ozone environment.
> >
> > I agree. Explicitly handling deletion of object in a application 
> > specific
> > manner is not that hard to achieve in the majority of cases _and_ is 
> > much
> > faster than a generic GC. Anyway, Jerry, a generic GC for sure would 
> > be a
> > great enhancement of ozone. If you need it then it would be great if 
> > you would
> > help to come up with a solution.
> >
> >
> > Falko
> >
> 
> An unscientific analysis of my application makes me think that it would 
> probably double the complexity of my code to track references - perhaps 
> even more if I want to eliminate the chance of circular references 
> causing a leak. My app is really very simple but the data can be very 
> intertwined.
> 
> I my not be the right person to build GC into ozone, but here are some 
> thoughts on what the requirements would be. If you can show me a quick 
> and easy way to traverse references maybe I'll take a shot at it.
> 
> 1) should be scheduleable. It could be a significant performance hit, so 
> you want to be able to control when it happens. App developers could 
> inform users when GC is taking place so they will understand why things 
> are slower.
> 2) Should be transactional. Obviously, if database state changes during 
> GC no data should be lost.
> 3) Objects stored by name should never be garbage collected. These would 
> be considered root objects.
> 
> Off the top of my head, I can think of a couple of different methods for 
> GC - one would be a two-pass system where you traverse all objects that 
> can be reached from a root and mark them. A second pass looks at every 
> object in the database and deletes unmarked objects. Any objects that 
> are locked during the first pass would be considered reachable. You have 
> to make sure that objects created between the two passes are marked 
> appropriately. Another method could be to start from the roots and copy 
> any object found to a new database. After all objects are copied, the 
> first database is deleted. This can also help to group related objects 
> together in the database. Once the copy process starts, all new objects 
> created in other transactions would be created in the new database.
> 
> Of those two methods, I like the first one better, but the second one 
> does reduce fragmentation. There are probably other ways to do it also. 
> The hardest part seems to me to make the process robust enough that 
> objects can be created and destroyed in other threads without breaking 
> the GC.
> 
> Jerry
> 
> >> Reason
> >> http://www.exratio.com/
> >>
> >> ----- Original Message -----
> >> From: "Jerry Seeger" <vikingjs@mac.com>
> >> To: <ozone-users@ozone-db.org>
> >> Sent: Monday, April 09, 2001 7:01 PM
> >> Subject: garbage collection?
> >>
> >>
> >>> Does ozone do garbage collection? I have objects that may be parts of
> >>> several different collections and I sure don't want to have to keep
> >>> track of the number of references to each one to know when to remove 
> >>> it
> >>> from the database. This could be a deal breaker for me - the whole
> >>> reason I want to use an OODBMS is so I can have very complex
> >>> interrelationships and treat them just like regular Java code.
> >>>
> >>> Jerry Seeger
> > --
> > ______________________________________________________________________
> > Falko Braeutigam                              mailto:falko@smb-tec.com
> > SMB GmbH                                        http://www.smb-tec.com
> >
> 


--
________________________________________________________________
Gerd Mueller                                    gerd@smb-tec.com     
SMB GmbH                                  http://www.smb-tec.com