directory-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Emmanuel L├ęcharny <elecha...@apache.org>
Subject Re: DN serialization issues
Date Sat, 19 Feb 2011 00:10:43 GMT
On 2/19/11 12:24 AM, Alex Karasulu wrote:
> On Fri, Feb 18, 2011 at 8:17 PM, Emmanuel Lecharny<elecharny@gmail.com>wrote:
>
>> Hi guys,
>>
>> once upon a time, in order to improve the server permformance, the DN was
>> serialized with its normalized value. This was to avoid a costly
>> normalization when we pull back the DN from the backend. But now that we
>> don't store anymore the DN into the entry, it does not make any sense to
>> store the normalized DN.
>>
>> We should get rid of that.
>>
>>
> +1
>
>
>
>> Another problem is that the LogManager also serialize entries with a full
>> DN on the disk, and when it reads them back, it should be able to inject the
>> schemaManager into the DN, which is not done.
>>
>> All in all, the DnSerializer has nothing to do in the Ldap-API. It's a
>> Server thingy, as is the EntrySerializer. Moreover, the DefaultEntry
>> implements the Externalizable interface, but does also provides
>> serialize()/deserialize() methods, which export the RDN, not the DN, simply
>> because it's used only by the server.
>>
>> This is a mess...
>
> Separating out the implementations might help decouple these server side
> ONLY concerns. But I don't know how I feel about having to have a ServerDn
> verses a regular Dn.

This is what we had once upon a time, and it was, well, awful.
What I'm trying to do right now is to make all the components schema 
aware (ie, DN RDN, AVA) and just store the minimum information when 
serializing them (ie, just serialize the UP types and values), assuming 
that the normalized values can be deduced using the SM, if it's injected.

That should help on the server side, because the SM will always be 
available on the server. Also the burden (and cost) of normalizing a 
serialized value on the server (something we have to deal with in three 
places only : the backend, the session and the ChangeLog) will not be 
that high, assuming that we will have an entry cache later, that  the 
changeLog can be desactivated and that we anyway have to do the job on 
the session side.

This should work, but it's quite painful as it implies a *lot* of 
modifications in the AVA and Rdn classes.

We also have to deal with the different serializer we have, the static 
ones we use in the server, which must take a SM as a parameter.


-- 
Regards,
Cordialement,
Emmanuel L├ęcharny
www.iktek.com


Mime
View raw message