[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Ozone object identity...
David Li wrote:
>
> There are two stages of my requirement here.
>
> 1. For our RDF database, we have a lot of anonymous objects that are
> tedious to be named. These objects are containers for other objects and
> need to be searched (indexed) by its component's attributed.
>
> In a more concrete way in the context of RDF, a Model is a set of
> Statement. A Statement is simply a triple of (Resource, Resource,
> String) or (Resource, Resource, Resource). The query on Model is to give
> an "template" triple with null acting as a wildcard and retrive all
> statements that match the template.
>
> We want to support indexing on all three elements. Given a template
> statement, we want to have all matching statement returned.
>
> As RDF is quite verbose (generating a lot of statement), it would be
> nasty for an implementation to name all of the statements and keep track
> of the uniquness of the names.
>
> In this requirement, we only need something unique with in an instance
> of Ozone database.
Have I completely misunderstood the Ozone architecture?
I thought a simple Java reference to an Ozone object would be unique
within an Ozone database...
In my eyes, the identity object is needed only for refering from an
external VM.
> > My suggestion was to use Object as the minimal interface
> > for the identifier, so that the API wouldn't be locked to
> > a particular identity class for all future.
> >
Identities of persistent objects have to be at least Serializable, of
course.
> > What type should getKey() return? It should be something
> > primitive. If one can ensure GEU using long (which I doubt),
> > let it return long. I know that byte[] will always work,
> > and be generic enough. Any OzoneObjectIdentifier will in
> > effect be a wrapper around the thing that getKey() returns.
No, the concrete type of the "persistent identity" should not
be specified. Neither byte[] nor String nor int...
This depends on the conrete implementation of the database/object
server.
> I totally agree with this approach. Let me put this in a more
> implementation context and see if we can agree on.
>
> We need to add one identity interface with the following properties.
> Let's call it OzoneObjectIdentity for the sake of discussion.
This interface should be something general, not dependent on Ozone.
So I prefer naming it "Identity" or "ObjectIdentity" or "Handle" (as in
EJBHandle).
> interface OzoneObjectIdentity {
extends Serializable !
> /**
> * must return hash code. The return value is
> * for hashing purpose only. It doesn't carry
> * any meaning.
> */
> public int hashCode();
>
> /**
> * this methods carry additonal semantics for
> * the object returning the identity in which
> *
> * ozOne.identity().equals(ozTwo.identity())
> * IF AND ONLY IF
> * ozOne is identical to ozTwo
> */
> public boolean equals();
>
> /**
> * toString will return a String value with the
> * following properties.
> *
> * ozOne.identity().toString().equals(ozTwo.identity().toString())
> * IF AND ONLY IF
> * ozOne is identical to ozTwo
> */
> public String toString();
> }
>
> OzoneRemote will be extended to have one additional method
>
> public OzoneObjectIdentity identity();
>
> OzoneInterface will be extended to have an additional method
>
> public Object getObjectByIdentity(OzoneObjectIdentity identity);
There should also be the other way in this interface:
public ObjectIdentity getIdentityOfObject(OzoneCompatible object);
and additional Exceptions like
NotThisDatabaseException...
What about a method to convert a String representation of the identity
to the identity (or to the object)?
>
> -----
>
> Here are some thoughts on some possible implementation.
>
> For the current Ozone implementation, it could probably get away by
> wrapping the OzoneObjectIdentity with the long value used by the
> container for the object. The serialization form of that identity is a
> string of digits.
>
> For the cached implementation, it may returned a OzoneObjectIdentity
> with additional inforamtion on host, port and class info as propsed by
> my previous mail.
>
> ---
>
> The format of the information on the seralized or stringified object
> identity are for the database implementor only. No info on this should
> be visible to the API's users.
>
> ---
>
> So, how about this? Can we accept this as a extension to Ozone?
Yes.
>
> David Li
> DigitalSesame
Falko wrote:
> OzoneRemote was meant as a tagging interface only. Adding methods to it means
> that we have them on _both sides, database and proxy. So OzoneCOmpatible and
> OzoneObject would have to provide implementations for it.
>
> The straight forward way is to add it to OzoneProxy but then we need an
> additional cast...
In the current version of ozone, OzoneObject does not implement
OzoneRemote
(and OzoneCompatible does not extend it...)
I even can't see any meaning in having OzoneProxy and OzoneCompatible
deriving
from the same interface.
One other argument for not using String as the identity:
The reference could be passed from one client to another.
On the other client, it would not be pooled with intern(),
so the == comparison would fail.
Remember that the identity can not be GEU in all cases, e.g.
when using a local database or a RemoteDatabase in an intranet.
The identity can store as many informations as possible about the
object location, but global uniqueness is not ensured.
Michael Keuchen