Portions of the DNA plug-in leverage the cached configuration information, while
other portions do not. In particular, the actual configuration related to
determining the next value to assign always does an internal search on the
configuration entry instead of using the in-memory information that it already
The DNA plug-in should never need to read from it's configuration entries aside
from startup. If a modification is made to the configuration entries directly,
we will detect that at the post-operation stage since we register a callback to
check for configuration changes.
Created attachment 313050 [details]
This fix makes the main functions that deal with allocating a new value use the
cached configuration information instead of doing an internal search for the
configuration entry. This basically just involves using the cached information
that we already hold and eliminating the internal search, but a few other
changes were required.
Since we are using the cached information, we need to be sure to update the
cached information after we allocate a value. This is done in
I also modified the parameters passed to a few helper functions. We used to
pass some of the config entry members separately, but it's better to just pass
the entire cached configuration entry to these functions.
There was some unnecessary code in dna_get_next_value() that would make 3
attempts at updating the "dnaNextValue" attribute in the configuration entry in
the database. This was designed this way before a mutex was added to protect
the allocation of a new value within a range. Now that a lock exists, these 3
attempts are not needed as it's not possible to contend with another thread in
this portion of the DNA code. Since a mutex is used now, I also changed the
operation that updates "dnaNextValue" to use a replace operation instead of a
value delete/value add. The delete/add was intended to detect thread
contention in case the explicit value delete failed.
One other change that was made is that the "newval" parameter that is passed
into dna_first_free_value() is no longer used to determine the next free value
to use. Previously, the caller would pass in the value that it thinks is the
next free value, and dna_first_free_value() would verify if it was indeed free.
If it was not free, then "newval" was modified to be the true next free value.
The new version of dna_first_free_value() simply checks if the nextval in the
cached configuration is free, and finds the real next free value if it is not.
This is then filled into the "newval" parameter that was passed in.
Checked into ldapserver (HEAD). Thanks to Noriko for her review!
Checking in dna.c;
/cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v <-- dna.c
new revision: 1.7; previous revision: 1.6
Please add steps to verify this bug, if it is possible for QE to do. Thanks
This fix is a code optimization, and is not verifiable by QE. Marking as VERIFIED.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.