The amazing adventures of Doug Hughes

Last week I blogged about a bug I found in ColdFusion MX when you loop over queries in the application scope. Perversely, the standard behavior of ColdFusion MX is to store the CurrentRow variable in the application scope along with the query. This means that two people looping over the same query in the application scope will run into a race condition.

One of my coworkers has been working with Macromedia support to resolve this issue. According to my coworker (and not to me) Macromedia is developing a HotFix for this issue. To the best of my knowledge this is not yet released. However, my coworker has tested it on the site where we found the problem. At least in the beta of the hot fix the behavior will change somewhat. The following code will continue to be susceptible to the bug:

<cfoutput query="application.myQuery">
#application.myQuery.currentRow#<br>
</cfoutput>

The reason this code will be susceptible to the problem is because it pulls currentRow directly from the application scope. You can think of this as the way to find out the current row in any loop in your site.

However, if you want to find the current row of your loop be sure to only reference it as currentRow as follows:

<cfoutput query="application.myQuery">
#currentRow#<br>
</cfoutput>

After the HotFix is applied currentRow does not exist in any of the standard scopes and exists only in cfoutput and cfloop tags. This is not the behavior in the unpatched version.

So, look for this HotFix on a macromedia.com site near your home.

Comments on: "Follow up to Bug Found When Looping Over Query In the Application Scope" (6)

  1. Sean Corfield said:

    I still say this isn’t a bug per se but a simple consequence of doing something inherently unsafe: namely using shared variables in a multi-threaded environment! 🙂

    Like

  2. Doug Hughes said:

    First off, oops – forgot to spell check that post before it went up. That’s fixed now.

    Secondly, I don’t disagree with you Sean. I would say that there are much better ways to handle caching queries. However, agree or disagree, that’s not the path taken in the application where this bug was encountered. Either way, I’m neutral.

    However, I do feel that Macromedia is doing the right thing by issuing this particular fix. One reason is that when programmers do store query data in the application scope that using a loop-specific currentRow variable will probably provide the best performance compared to either duplicating the query or using an exclusive lock. (I can almost hear Sean asking what happens when the data in the query changes and I’m not arguing that point!) I also think that most coldfusion programmers intuitively expect cfloop and cfquery to function as the new patch will make them.

    The only problem I see is that it seems somewhat inconsistent to have application.myQuery.currentRow be different from currentRow. Oh well.

    Like

  3. Sean Corfield said:

    Heh, the only thing I can say about iterating over application scope data like this is…

    DON’T DO IT!

    Seriously tho’, caching the query is sort of understandable but if the real intent is to generate a global nav bar, why not generate it once and cache it instead of iterating over the query in every request?

    Like

  4. Sean, I must be missing something here. Are you saying that this isn’t thread-safe?

    &lt;cflock scope=&quot;application&quot; type=&quot;readonly&quot; timeout=&quot;5&quot;&gt;
    &lt;cfoutput query=&quot;Application.objApp.ItemData&quot;&gt;
    #itemid# – #itemtitle#
    &lt;/cfoutput&gt;
    &lt;/cflock&gt;

    Like

  5. Sean Corfield said:

    Oh it’s thread-safe if you put a lock around it but you’re going to single-thread the code that stores the query into application scope (against the multiple readonly threads).

    How often does the query get updated in application scope?

    Like

  6. Usually not more than once a day.

    Like

Comments are closed.

Tag Cloud

%d bloggers like this: