Re: Some questions about Ozone

[Falko Braeutigam <falko@smb-tec.com>]

On Mon, 07 May 2001, Daniel Weinreb wrote:
> Hi.  I saw the announcement that Ozone 1.0 was released, and I
> downloaded the sources just out of curiosity to see how it works.
> It's very interesting and I really enjoyed looking at it.  I have a
> few questions that I was wondering if someone be so kind as to answer.
> 
> I don't understand how KeyGenerator guarantees uniqueness in the face
> of a system crash.  When it advances idBorder, shouldn't it force its
> state out to disk before it returns the next ID number?
This was a bug. See the new version 1.0.1

> 
> I also don't understand how recovery works on the name table.  What if
> there is a system crash in the middle of commitNameTable?  
then the name table file is corrupt which forces the server to recover the name
table from the clusters on the next start up.

> Isn't some
> kind of shadow file needed here?
the info is already redundant (name table file and clusters)

> 
> I don't understand how the beginExclusive(), commitExclusive(), and
> checkExclusion() mechanism work.  If a method M calls
> checkExclusion(), and some other thread is inside a
> begin/commitExclusive(), then it will wait; that's fine.  But as soon
> as checkExclusion is done waiting and checkExclusion returns to M,
> some other thread might enter a beginExclusive() again, before the
> rest of method M is executed.
Hmmm... maybe I don't fully understand the question.

begin/end/checkExclusion() implements a simple semaphore. It allows to make
sure that a specified code block (not method) is executed by 0 or 1 thread only
at one time. The problem with semaphores is that check/set must be a atomar
operation - which is the case for the ozone code. (at least as far as I can see
;) So where do you see a problem?

> 
> In Object2XML: Do you really think it's safe to use
> System.identityHashCode to generate ID numbers?  These ID numbers
> ought to be unique, but two distinct objects can have the same
> identity hash code.  The usual design pattern that I've seen in such
> cases is to use a hash table to record the binding between objects and
> id numbers.
My JDK doc says that "the hashCode method defined by class Object does return
distinct integers for distinct objects" and identityHashCode() "Returns the same
hashcode for the given object as would be returned by the default method
hashCode()"... This is exactly what we need in the Object2XML code. Do I miss
something?

> 
> Suppose you are using JTA, and the transaction manager calls
> XA.prepare on some xid, and then you crash, and then you come back up,
> and then the transaction manager calls XA.recover.  It would seem that
> you ought to return that xid in the reply.  However, as far as I can
> tell, Ozone recovery never restores Ozone to a state where there is a
> prepared transaction in existence.  (I am not experienced with JTA and
> perhaps I an misinterpreting how it should work or something.)
You are right, JTA support is not complete.

> 
> And also:
> 
> Cluster.abort() calls deleteShadow() to delete the shadow file.  But
> it does this right after calling restoreShadow(), which has just
> renamed the shadow file, so the call to deleteShadow appears to be
> superfluous.
> 
> ClusterStore.updateLockOnDisk is only called from two places, both of
> which have released the lock and deleted the lock file already, so it
> appears to be overly general (if you care about that sort of thing).
> 
> The comment in front of OzoneObject.toXML says "This default
> implementation of the toSAX() method.", presumably left over from
> before a rename of the method.
> 
> The comment inside UserManager.checkWritePermission says "allRead can
> be checked"; it should be allWrite.
> 
> I understand that the ClientCacheDatabase feature is considered to be
> experimental and undocumented.  But even so: In ClientObjectContainer,
> I think clearState() ought to set tx to null.  And touch() should set
> lastTouched.

Wow, seems that after having a brief look at the sources you are more familiar
with the code base than me ;) I will take a look (and comment on) the 5 points
above tommorow.

Thanks for your comments!


Falko
-- 
______________________________________________________________________
Falko Braeutigam                              mailto:falko@smb-tec.com
SMB GmbH                                        http://www.smb-tec.com