Path: news.daimi.aau.dk!news.uni-c.dk!sunic!sunic.sunet.se!columba.udac.uu.se!news.mdh.se!news.seinf.abb.se!eua.ericsson.se!erinews.ericsson.se!cnn.exu.ericsson.se!convex!cs.utexas.edu!news.sprintlink.net!EU.net!Germany.EU.net!Dortmund.Germany.EU.net!Informatik.Uni-Dortmund.DE!news
From: grossjoh@groucho.informatik.uni-dortmund.de (Kai Grossjohann)
Newsgroups: comp.lang.beta
Subject: A Coule of Questions on Persistence in Beta
Date: 12 May 1995 10:00:01 +0200
Organization: University of Dortmund, Germany
Lines: 69
Message-ID: <vafhh70263q.fsf@groucho.informatik.uni-dortmund.de>
Reply-To: Kai Grossjohann <grossjoh@ls6.informatik.uni-dortmund.de>
NNTP-Posting-Host: groucho.informatik.uni-dortmund.de
X-Newsreader: (ding) Gnus v0.65

Hi there,

I would like to store large amounts of data on secondary storage.
(Large amounts here means that only a small fraction of the whole data
will fit in virtual memory.)  Possibly the PersistentStore mechanism
is a way of doing this.  Is it?

Reading

        The Mjolner BETA System
        Persistence in BETA
        Reference Manual
        [MIA 91-20 (1.2)]

I have come across the following questions.

Say I would like to store a list of tuples on secondary storage and
would like to iterate over that list (thus `scanning the relation', in
RDBMS terms; I'm taking a _very_ simple minded approach here, though).
Let's say each tuple is to be printed on the screen.

I see that I can tell the list of tuples to be a persistent root, and
that I can use the `lazy fetch' mechanism to achieve that only the
actually referenced objects (tuples, in this case) will be retrieved
from secondary storage.  I did not understand the GC part of the
paper:  When a tuple has been printed on the screen, it need not be
kept in main memory any longer.  Is there any way of achieving that
the object is deleted from main memory soon after it has been printed?
There was something in section 5.1.1 of the above mentioned document
that led me to think that a tuple printed on screen will not be
garbage collected until the persistent store is being closed.  Is this
true?

There is an existing design which I am to retrofit with persistent
storage.  It is still possible to change that design, but I will need
good reasons for that change.

The design states that _always_ references to objects are being used.
There is a `database' class, and the `enterTuple' method expects a
reference to a tuple as input parameter.  After inserting the object
into the database, the reference is still valid, and changing the
tuple referenced will change the tuple in the database.  This is all
happening in main memory, so far.

Now, retrofitting this design with storage of tuples on secondary
storage would mean that I somehow come up with a mechanism for finding
out when an object already inserted into the database is changed, so
that the copy of said object on secondary storage can be updated.

Is any of this possible using PersistentStore?

I have heard of OODB and suspect that it might do what I want.  I
would like to go with the simpler PersistentStore mechanism, though,
since I do not require concurrency control mechanisms and so on.  In
case PersistentStore does not do what I want, will OODB be able to do
this?

How does OODB fare with respect to the existing design of always using
references to objects?  Will that design have to be changed in order
to accomodate keeping objects on secondary storage using OODB?

Thank you very much in advance for taking your time to read this and
for providing me with any hints you might have to offer.

Regards,
        \kai{}
--
Life is hard and then you die.