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.




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




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.


-----Original Message-----
From: jdbm-developer-admin@lists.sourceforge.net
[mailto:jdbm-developer-admin@lists.sourceforge.net] 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


Comments below.




------------------------------------------------------- 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 Jdbm-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jdbm-developer