Thanks Sean for your response...I really appreciate it. I originally left a post on livedocs about cffile and was contacted by MM. However, Rand Neilsen asked a developer about the thread safety of cffile global scope. I received an email from Randy and he basically referred me to you and your blog entry. Although, he did mention:

"My technical opinion (which you should take with a grain of salt, as I am just a Tech Writer) is that cffile should be thread-safe, period, and if it isn't, that's a bug."

That's why I brought up cfcatch. It would seem to be that cffile and cfcatch are "thread safe" and in the same boat togeather.

Thanks again Sean...a valuable KB you have!
.Peter
MaePub

*Below are more comments:*

Sean Corfield wrote:

On Fri, 03 Sep 2004 18:15:03 -0400, Peter J. Farrell
<[EMAIL PROTECTED]> wrote:


I have a try/catch block in one of my CFCs. It cannot be var'ed into
the "private" scope....


Correct, despite what an old entry on my blog says. Sorry 'bout that.


I figured that one out pretty quickly.

If I want to return the cfcatch "global" scope back from my CFC in a
structure using duplicate(cfcatch).


Why duplicate it?


Check this out: To pass the CFCATCH variable to a UDF expecting a structure you have to duplicate() it.

http://www.rewindlife.com/archives/000135.cfm

It seems to be true if you want to return cfcatch from a function from a try/catch block from within the function. On my MX6.1 enviroment, it only seems to work when using duplicate(cfcatch). However, you want bring up encapsulation and the like - I adhear and fully understand the usefulness of it.

If this thread safe?



I just did an experiment which convinces me that cfcatch is created on
the fly for every cfcatch block executed, even in the same thread. So
I think cfcatch is thread safe, without needing to do anything fancy
for...


This makes sense and I'll institute this as policy until I run into problems.
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.


CFCDev is run by CFCZone (www.cfczone.org) and supported
by Mindtool, Corporation (www.mindtool.com).

An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]

Reply via email to