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

Some questions about Ozone



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?

I also don't understand how recovery works on the name table.  What if
there is a system crash in the middle of commitNameTable?  Isn't some
kind of shadow file needed here?

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.

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.

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.)

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.

Thanks very much!

-- Dan