Agreed. Something somewhere is not thread safe. Adding the lock is really just a band-aid, not a true solution. Also, an exclusive lock on the Application scope can have serious performance consequences. If you aren't, I'd use an exclusive named lock instead as a stopgap measure. But my real concern would be finding out where the race condition is actually coming from. If this one is showing up unexpectedly, chances are there are others that you just don't know about yet.
Regards, Brian On 7/16/07, Mark Mandel <[EMAIL PROTECTED]> wrote: > > Josh - > > This is not somewhere where a named lock should be required. > > This is a case of a variable somewhere along the stream not being > var'd properly. > > Mark > > On 7/17/07, Josh Nathanson <[EMAIL PROTECTED]> wrote: > > > Just curious, why do you care if multiple threads are reading the > database > > > from this gateway at the same time? > > > > > > There are always "race" conditions in shared scopes, but you only need > to > > > lock them when actually have consequences. > > > > It's a multi-tenant application. People in one account were seeing > other > > accounts' information. I'd say that counts as consequences. > > > > As I said I've never needed nor wanted to use locks before, but this > > definitely looks like a situation where one is warranted. > > > > I was thinking about using a named lock, but I thought since this CFC is > > cached in the Application scope that would be more appropriate. I'll > give > > the named lock a try. > > > > -- Josh > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Macromedia ColdFusion MX7 Upgrade to MX7 & experience time-saving features, more productivity. http://www.adobe.com/products/coldfusion?sdid=RVJW Archive: http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:283842 Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=11502.10531.4
