A user asks:
Is there a way I can cache cfldap query and how? I am running a cfldap query and it is taking too log. Can I use cfcache or there is a drawback to that?
There are a coulple of answers to this. First off, yes, you could use cfcache, and yes, there are drawbacks. If your LDAP query is session based, cfcache won't work for you since it is URL variable-based. The same applies if your query is form-based. If that isn't a problem for you, than cfcache will work great and will take all of one second to add.
Do not forget that you can also cache the results yourself. All you need to do is stuff the results in a persistent scope like Application, Server, or Session. The following pseudo-code shows an example:
<cfif not structKeyExists(application, "myldapquery")>
run the ldap query and name it application.myldapquery
</cfif>
use application.myldapquery
Obviously this technique works for any slow process yo may have. If you don't need to run it again, just store the results. What is nice is that you can also remove the cache easily enough by just using structDelete.
Lastly - the number one thing you should do before just caching - check to make sure there isn't something you can do to speed up that LDAP query. To be honest, I've rarely used LDAP, but if it was a normal query, I'd play around a bit with my sql and look into ways I can make it more efficient. Caching should only be used when you have exhausted every other attempt to speed up the code.
Archived Comments
Ray,
I think you should post a little more detail in the psuedo-code. The way it's portayed isn't thread-safe. You need to lock and double check the variable, otherwise one request could be using application.myldapquery while another is overwriting it. Something like this:
<cfif not structKeyExists(application, "myldapquery")>
<cflock name="LDAPQueryLock" timeout="100">
<cfif not structKeyExists(application, "myldapquery")>
run the ldap query and name it application.myldapquery
</cfif>
</cflock>
</cfif>
Regardless, my response would have been "don't use CFLDAP". We've long tossed it in favor of more performant java-based solutions (which are easily programmed in CFML).
I left the locking out on purpose, since in most cases, it won't be neded. Yes, N threads may run it, but 9 times out of 10 it won't matter. It will be a bit less effecient, but will end up with the same result. (Unless you are doing something funky like recording the creation time, and even then you may not care if the creation time is the last of N threads to make it.)
Dave, would you mind sharing some URLs or information on the java-built LDAP connectivity?
I am really interested in any examples/references that interact with group membership.
Thanks
Michael,
I've made a couple posts about LDAP, specifically JLDAP, and there is some code in there that should help.
http://www.d-ross.org/index...
http://www.d-ross.org/index...
http://www.d-ross.org/index...
JLDAP is really good for dealing with group memberships because you can access multi-valued attributes (like group membership) as an array, unlike CFMX where you get a long ugly string.
Hope that helps! Feel free to ask if you get stuck or have questions.