Menu
▾
▴
re[4]: [Jdbm-developer] record managment
|
From: Kevin D. <ke...@tr...> - 2006-04-11 18:44:26
|
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0
Transitional//EN">
<HTML><HEAD>
<STYLE type=text/css> P, UL, OL, DL, DIR,
MENU, PRE { margin: 0 auto;}</STYLE>
<META content="MSHTML 6.00.2900.2802" name=GENERATOR></HEAD>
<BODY leftMargin=1 topMargin=1 rightMargin=1><FONT
face=Tahoma>
<DIV><FONT face=Arial size=2>Bryan-</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT></DIV>
<DIV><FONT face=Arial size=2>The issue that
I have with enforcing a reference object
like this (especially at the core record
manager level) is that it pushes the developer
away from a natural way of working.
The database code winds up in the business
logic code, and all of what that entails.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>If we were using
default serialization, then we could do some
things with serialization proxies (I did
this succesfully in a project a few years
ago), but this kind of thing probably belongs
at a higher level in the system.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>Now, back to
the idea of using an object for OID...
we went through a lot of steps last year
to introduce a long->object map to jdbm
- this would pretty much invalidate that.
What are the implications of creating lots
of tiny little OID objects like this?
Generational GC is pretty good at handling
this kind of thing, but I think it's worth
discussing in light of the long->object
map work that we did.</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>What do you
think about using the Flyweight GOF
pattern instead. A single OID object
can be configured with the byte representation
(actually a long value), then the page and
slot can be retrieved in an object oriented
manner (instead of explicitly doing bit operations
in the consumers of the recids).</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2>- K</FONT></DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2></FONT> </DIV>
<DIV><FONT face=Arial size=2> </FONT>
<TABLE>
<TBODY>
<TR>
<TD width=1 bgColor=blue><FONT face=Arial
size=2></FONT></TD>
<TD><FONT face=Arial size=2><FONT color=blue>>
<BR>I am thinking of <BR> <BR>OID insert(
byte[] data ). <BR> <BR>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. <BR> <BR>For an application which
can not support floating OIDs, the OID would
be eagerly assigned exactly as it is
today. <BR> <BR>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. <BR> <BR>I would
see at least the following methods on OID:
<BR> <BR>long getPageId(); // just the
page identifier. <BR>int getSlot(); // the
slot on the page. <BR>long longValue(); //
the entire 64-bit long value. <BR> <BR>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. <BR> <BR>-bryan
<BR> <BR><BR><BR>From: <A href="mailto:jdb...@li..."><FONT
color=#0000ff>jdb...@li...</FONT></A>
<A href="mailto:jdb...@li..."><FONT
color=#0000ff>[mailto:jdb...@li...]</FONT></A>
On Behalf Of Kevin Day<BR>Sent: Tuesday,
April 11, 2006 12:00 PM<BR>To: JDBM Developer
listserv<BR>Subject: re[2]: [Jdbm-developer]
record managment <BR> <BR><BR>Bryan-
<BR><BR> <BR><BR>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... <BR><BR> <BR><BR>-
K <BR><BR> <BR><BR> <BR>>
I am wondering if we could define the record
management API in terms of an<BR>OID interface
and then provide for delayed conversion of
OIDs to 64-bit<BR>integers. After insert
but before conversion the OID would "float".
The<BR>conversion would happen when
the object was evicted from cache or the<BR>transaction
commits. At this point the OID would
be assigned and locked for<BR>the object.
I think that this would make it possible
to cluster OIDs based<BR>on the "mature"
state of the object.<BR><BR>Internally, the
OID object would maintain a long integer.
We need to<BR>differentiate an OID
which is NULL (0L) from one which is floating
(-1L?).<BR>All caching operations for records
would be defined in terms of OIDs.<BR><BR>I
would suggest a factory for OIDs. Different
stores might choose different<BR>pages sizes,
which would mean a different #of bits reserved
for the slot# on<BR>the page vs the pageId.
That context would have to come from
a factory<BR>associated with the store.<BR><BR>-bryan<BR><BR>-----Original
Message-----<BR>From: <A href="mailto:jdb...@li..."><FONT
color=#0000ff>jdb...@li...</FONT></A><BR><A
href="mailto:jdb...@li..."><FONT
color=#0000ff>[mailto:jdb...@li...]</FONT></A>
On Behalf Of Thompson,<BR>Bryan B.<BR>Sent:
Tuesday, April 11, 2006 6:32 AM<BR>To: Kevin
Day; JDBM Developer listserv<BR>Subject:
RE: [Jdbm-developer] record managment<BR><BR>Kevin,<BR><BR>Comments
below.<BR><BR>-bryan<BR><BR><<BR><<BR></FONT></FONT></TD></TR></TBODY></TABLE></DIV></FONT></BODY></HTML>
|