On 7/28/10 10:32 PM, Kiran Ayyagari wrote:
On Wed, Jul 28, 2010 at 4:37 PM, Emmanuel Lecharny<[email protected]> wrote:
On 7/28/10 11:31 AM, Stefan Seelmann wrote:
</snip>
I have just committed a DNFactory implementation [1].
Seems good to have.
But the real
issue with this is that
the ApacheDS's DN class is mutable and hence will cause issues[2].
Oh, yeah. DN should be immutable !
A working solution I have is to return a clone of the DN *all* the
time (whether a hit or a miss)
nah way too costly. I would rather forbid any modification on an
existing DN. Methods adding or removing RDNs from a DN should copy the
DN before applying the modification. The problem is that iterating throw
RDNs to create a DN will be costly. Code like :
RDN rdns = new RDN[] { rdn1, rdn2, rdn3, ..., rdn7 };
DN dn = new DN( "ou=system" );
for ( RDN rdn : rdns )
{
dn.add( rdn );
}
will see 7 copies to be created. Simply insane...
May be we should extend the API to have something like a add( DN, RDN )
method which allow a modification to be done without copy ?
this is guaranteed to work and am thinking that cloning() is way
faster than the time required for
parsing and normalizing a DN from the beginning. But one penalty we
pay for this solution is that
two instances(of which one is just a clone) will be created for every
DN miss in the cache.
We should think about what it would cost to make DN an immutable class,
and see what's the impact on the existing cost. I don't think we can
ignore the problem anymore...
--
Regards,
Cordialement,
Emmanuel Lécharny
www.iktek.com
