Cool Cool BarneyB, best single threaded blog about cross threading in shared scopes I've ever seen.
-Acker

Application-per-project would definitely work, and is probably the least invasive solution. Another potential would be to use the request-scope CFC as a facade for an application-scope CFC. So your change the CFC to accept dsn/dbo parameters and put it in the application scope, but you retain the request-scoped CFC which simply delegates to the application-scope CFC. So assuming the implementation I gave above was how the application-scope CFC was implemented, the request-scope CFC (which you're already using, and which wouldn't have it's API change), would look like this:

[cffunction name="getSomething"]
[cfreturn application.getSomething(request.dsn, request.dbo) />
[/cffunction]

You'd have a single instance of the facade CFC that gets copied into the request scope for each request, and a single instance of the "real" CFC that stays in the application scope. Then all you need to do is ensure request.dsn and request.dbo are defined and you're done.

I say my company needs to make an application name per project.
-Acker

Here's an example:

[cffunction name="getSomething"]
[cfargument name="dsn" /]
[cfargument name="dbo" /]
[cfquery datasource="#dsn#"]
select *
from #dbo#.mytable
[/cfquery]
[/cffunction]

Since the dsn and dbo are passed into each individual method invocation, you alleviate the threading issues. Method arguments and function-local variables (declared with 'var') are always single-threaded, because a method invocation is single threaded. It's only the instance state of a shared scope CFC that is shared.

cheers,
barneyb

I was so focused on the thread safe part, that I didn't consider the simplistic fact that it's in a shared scope.

To fix the problem I came up with the idea of separate application names, per dsn name.

B, could you please elaborate what you meant by "but if you just made the dsn/dbo arguments that are passed into the CFC, the problem should go away" … I think somethings missing in your statement.

If you have a CFC in application scope, then it's instance variables are in application scope as well. So it's no different than storing what is in the instance variables directly in the application scope. If you have per-request data, that needs to be passed into methods of application-scope CFC, rather than being part of the CFC's internal state. I don't know about your specific case, but if you just made the dsn/dbo arguments that are passed into the CFC, the problem should go away.

I think I've come to find you can't store a cfc in the application scope if it needs to be thread safe. I did find I could store a cfc that has not been init(), and then init it to the request scope. All you would gain here is that the cfc is loaded and waiting for use in a non-shared scope.

I'm having the issue that this particular cfc at work requires a dsn, dbo, and was stored in the application scope. Problem was that if another request with a different dsn/dbo came threw, and the application name was the same, they'd cross thread.

All in all I wanted to post somewhere that I don't think you can safely store a cfc that counts on it's variables remaining the same for a full request.

TIP!!!! ColdFusion 8 has cfThread with attribute action="sleep", this made it very easy for me to loop from="1″ to="100″ and sleep for 200milsecs on every loop. So it made it much much much easier for me to run other machines/browsers to attempt a cross thread.

Damn Descent post BarneyB. I've got a "Cynthia" type at my job too, mine is an impatient woman who wouldn't finish reading an article either, and quick to bash an article with comments such as "keep my hands from shaking".

I would be more than happy to post an alternate walkthough you provide, and/or link to one on your site if that would allay your fears of newbie confusion.

You're missing the point. People conceive of writing to an Application or session variable as one "step". Their confusion will be reinforced by the first example you used, where clearly there are two steps. Do query one, then do query two.

I remember having a hard time understanding why I needed to lock when I was first starting out. I corresponded with Ben Forta and he cleared everything up, and I can tell you that the way you are explaining things is most definitely going to leave newbies (and probably some others as well, sorry to say) with the wrong ideas.

I agree (to some extent) with your first statement that the CFQUERY-based example is "odd". I do explicitly list both transactions and relative updates as solutions (the latter being preferable) to the problem. However, the reason for using queries is that the order of events is a lot more clear cut than . That statement is both a read and a write in a single expression – hardly clear that there are two distinct and fundamentally different operations happening.

Regarding your second point, you're wrong. A race condition can ONLY exist where there are multiple steps. If the "process" is an atomic single action, you CAN'T have a race condition. You can easily replace "requests" in my statement with "threads" if you prefer that language, but the "multi-step" requirement is still in force. This is the reason that a relative update on a database is safe to perform without a lock or a transaction: it's a single atomic operation so a race condition is impossible.