Hide Forgot
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 has available. 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] CVS Diffs 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 dna_notice_allocation(). 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 done
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. http://rhn.redhat.com/errata/RHEA-2009-0455.html