RE: re[2]: [Jdbm-developer] record managment

[Thompson, B. B. <BRY...@sa...>]

I am thinking of

 

OID insert( byte[] data ).

 

I think that the policy could be configurable.  For an application which
could support floating OIDs, the default would be to defer the assignment of
the 64-bit identifier until the record was serialized and allocated on a
page image.  The big win here is in clustering of OIDs and/or records based
on their "mature" state.

 

For an application which can not support floating OIDs, the OID would be
eagerly assigned - exactly as it is today.

 

I think that we might benefit from an OID object for several reasons, not
the least is that it will end our constant creation of Longs.

 

I would see at least the following methods on OID:

 

long getPageId(); // just the page identifier.

int getSlot(); // the slot on the page.

long longValue(); // the entire 64-bit long value.

 

Supporting floating OIDs would require the application to abstract the
reference to the persistent object.  What I had in mind for the GOM
framework was supporting persistence by reachability - an object which is
not reachable from a named (root) object in the store is not persistent and
will never be assigned a fixed OID.  This gives you the same functionality
for transient and persistent data, which is nice.

 

-bryan

 

  _____  

From: jdb...@li...
[mailto:jdb...@li...] On Behalf Of Kevin Day
Sent: Tuesday, April 11, 2006 12:00 PM
To: JDBM Developer listserv
Subject: re[2]: [Jdbm-developer] record managment

 

Bryan-

 

Given that the insert() operation returns a recid that is then used
extensively by other objects in the store, how do you see this working?  Are
you talking about not having a long recid that is returned for object
references, but instead having some sort of 'reference' object?  I do this
in my applications, but you have to handle serialization specially for the
reference objects...

 

- K

  


 

> I am wondering if we could define the record management API in terms of an
OID interface and then provide for delayed conversion of OIDs to 64-bit
integers.  After insert but before conversion the OID would "float".  The
conversion would happen when the object was evicted from cache or the
transaction commits.  At this point the OID would be assigned and locked for
the object.  I think that this would make it possible to cluster OIDs based
on the "mature" state of the object.

Internally, the OID object would maintain a long integer.  We need to
differentiate an OID which is NULL (0L) from one which is floating (-1L?).
All caching operations for records would be defined in terms of OIDs.

I would suggest a factory for OIDs.  Different stores might choose different
pages sizes, which would mean a different #of bits reserved for the slot# on
the page vs the pageId.  That context would have to come from a factory
associated with the store.

-bryan

-----Original Message-----
From: jdb...@li...
<mailto:jdb...@li...> 
[mailto:jdb...@li...]
<mailto:jdb...@li...>  On Behalf Of Thompson,
Bryan B.
Sent: Tuesday, April 11, 2006 6:32 AM
To: Kevin Day; JDBM Developer listserv
Subject: RE: [Jdbm-developer] record managment

Kevin,

Comments below.

-bryan

<

 

------------------------------------------------------- This SF.Net email is
sponsored by xPML, a groundbreaking scripting language that extends
applications into web and mobile media. Attend the live webcast and join the
prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________ Jdbm-developer mailing list
Jdb...@li...
https://lists.sourceforge.net/lists/listinfo/jdbm-developer