directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alex Karasulu" <>
Subject Re: [LDAP DAS] Efficient Updating of Persisted Objects
Date Thu, 29 Mar 2007 00:58:39 GMT
Hi Ole,

Excuse the late response ... I've been lazy while on vacation.  More inline

On 3/28/07, Ole Ersoy <> wrote:
> Alex Karasulu wrote:
> > Ole,
> >

SNIP ...

> Hmmm with heirarchical services in JNDI you should not be using
> > bind().  You
> > should be using the createSubcontext() and modifyAttributes() methods
> > instead.
> Oh OK.  My impression was that I would use createSubcontext() when
> creating a new context for a serialized java object for example.

Oh sorry I thought you were not storing a serialized object.  Then bind()
help you accomplish that I think.  However this is not very efficient
of the reasons you mention: you would in essence be updating the entire
when just one member changes.  And you're dealing with a blob of serialized
data which is bigger.  Meaning the transfers are bigger for a small change
in the
overall object.

My impression was that you were converting an object into an entry with
for it's properties which is more like what you do when you persist an
object in a
record in a database.  For example you have a User object and you convert
into a set of attributes like so:

givenName: johny
surName: walker
commonName: wiskey
age: 12

etc ...

Then this way you would call createSubcontext with the attributes and that
persist the entry.  If you change the age to 15 then there is a single
update operation
on that attribute.  Also this way indexing can be taken advantage of for
attributes for
speeding up search.  I have no idea how you would search for serialized
objects in
a directory efficiently.

Let me give an exampel - I'll be starting the DAS "serious" work tomorrow,
> so if I'm off on this, I'll eventually find out :-), but this may help
> facilitate
> the conversation with respect to updating attributes vs. the entire
> object.
> Suppose my initial context is:
> |uid=ole,ou=users, ou=system
> |
> And I wanted to add a sub context for an Instance of MyClass
> with reference named myClassInstance
> I could do something like
> ctx.createSubcontext("cn=myClassInstance");
> Which would create the context:
> |cn=myClassInstance, uid=ole, ou=users, ou=system|

I think you were right in using bind() where you provide the object to
serialize.  This createSubcontext() operation will merely create a
javaContainer I think.  There's an
RFC on this which I implemented a while back and you can find more info in
JNDI tutorial about this as well.

However again I don't think using this serialization mechanism is such a
good idea
because of the search implications.  How would you search a blob of binary

Then to store a my serialized myClassInstance under this dn in a
> javaSerializedData attribute, I would do something like this:
> |||String bindContext = "cn=|myClassInstance|,uid=ole,ou=users,
> ou="system";|
> |ctx.bind( bindContext, ||nameOfMyObject||)
> I'm also guessing that the bind operation would take care
> of the createSubcontext() step for me, ... but anyways...

Yes you were right.  Actually you would not need to createSubcontext()
operation at all just use bind().

I recommend just going through the JNDI tutorial on this stuff and testing
these operations on the server just to see what happens.

> > You
> > might want to go through the JNDI tutorial for LDAP just to get a good
> > feel for how to
> > work with non-flat namespaces using JNDI.  Namely with LDAP you don't
> > need to
> > rebind the object with a modification to an attribute.  This is what
> > the modify
> > operations are for.
> Just want to make sure we are talking about the same thing here.
> We may have some attributes stored in ADS under:
> |DN: uid=ole,ou=users, ou="system
> This DN has the Person ObjectClass associated with it.
> So I may wish to change one of the attributes (The password attribute
> for instance)
> that are associated with the Person ObjectClass.
> Then I could see using a modify operation.

Yeah we're mixing object serialization here with converting that object to
an entry with attributes.

Is that also the case when storing entire javaObjects
> in a javaSerializedData attribute?

Technically you can use modify on javaSerializedData but you're replacing
the blob of serialized bytes representing the serialized object.

> |I just want to make sure we are clearly separating java object
> attributes (Primitive java class members)
> from LDAP attributes.

Basically my advice would be to stay clear of using java serialization in
the directory.

Let me stop here in case I'm making any sense?
> If not hopefully once I'm done writing the design guide and get a
> terminology and concept section going
> things will be a little clearer.
> >
> > <
> >,
> > int,
> >
> >
> Cool - I'll have a looksee - I've been using the articles on the
> ApacheDS website as a reference so far, but the more material the better.
> >
> >
> >     Initially I  was thinking that the object's attributes (primitive
> >     properties - not references to other objects)
> >     would be serialized and made into directory attributes.  But I think
> a
> >     LDAP ObjectClass schema that corresponds to the
> >     object's class (The class of the object we are persisting) would
> >     have to
> >     be generated and stored along with the instance.
> >
> >     This might lead to performance improvments, if doable...?
> >
> >     Thoughts?
> >
> >
> > Hmmm I think some of your premisses in this question may be due to
> > considering the use
> > of bind() instead of using modifyAttributes() and createSubcontext().
> > If you use these methods
> > I think there is no further preformance issue to consider.  WDYT?
> Ahh - This is the part where I need clarification.
> If we serialize an entire object to ApacheDS, then we have to get it
> from ApacheDS,
> update it, and send it back to be stored in a javaSerializedData
> attribute right?

Right exactly!  This is why java LDAP serialization is not a good idea for
your DAS thingy.

For instance I may have a Class called UserClass with a String member
> userName.
> I create an instance of UserClass called userClass.
> The I do
> userClass.setUserName("ole");
> Now I want to store userClass in ADS here:
> |DN: cn=|userClass|,ou=users, ou="system
> So I do this:
> ||String bindContext = "cn=|myClassInstance|,ou=users, ou="system";|
> |ctx.bind( bindContext, ||userClass||);
> Now userClass is in ADS stored as a javaSerializedData LDAP attribute
> value,
> hanging off of the bindContext I specified.
> Later when I want to update
> the userName member of the UserClass instance I serialized to ADS,
> I need to use JNDI to load the instance again right?

Yep unless you write the code to resusitate the serialized object manually.

Then update userName.  Then serialize userClass back to ADS again?


> I mentioned some stuff about generating an ObjectClass schema that is
> the LDAP schema of the Java Class UserClass,
> so that the primitive members (That have java primitive types) would be
> stored as LDAP atttributes rather than storing the entire
> object as a single javaSerializedData attribute attached to a DN.

Yes this would be best in my opinion.


View raw message