I have to agree with Salvatore.
 
duplicate(cffile)
 
This is just copying an instance variable. If the instance is shared, you have a race.
 
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Brian Kotek
Sent: 11 May 2006 17:32
To: [email protected]
Subject: Re: [CFCDev] MVC File upload

But couldn't you just do this?

<cffunction name="processUpload" access="" returntype="void" output="false" roles="" hint="">
    <cfargument name="fieldName" type="string" required="true" hint="" />
    <cfset var local = structNew() />
    <cflock type="exclusive" name="processUploadLock">
        <cffile action = ""
               fileField = "#arguments.fieldName#"
            destination = "path and file name" />
        <cfset local.cfFileResult = duplicate(cffile) />
    </cflock>   
</cffunction>

To explicitly ensure that you have a method-local copy of the cffile result structure under CFMX 6.1?


On 5/11/06, Salvatore Fusto <[EMAIL PROTECTED]> wrote:
this is not, in my opinion, a race condition such us the concurrent access to a shared variable, that we can avoid with a cflock: in cfmx6, we have not the result attribute, so cffile struct is variables-scoped, so continue to persist after the cfile call.
regards
salvatore
ps: this is my very personal opinion
----- Original Message -----
Sent: Thursday, May 11, 2006 6:17 PM
Subject: Re: [CFCDev] MVC File upload

Yes that's true. However even on CFMX 6.1 is this really a problem? Couldn't you use cflock to single-thread access to the cffile code if a race condition was really a concern, instead of recreating a separate CFC instance on every reqeust just to perform the cffile call?

Thanks,

Brian

On 5/11/06, Salvatore Fusto <[EMAIL PROTECTED]> wrote:
Result attribute is valid only on cfmx 7
regards
salvatore
----- Original Message -----
Sent: Thursday, May 11, 2006 6:03 PM
Subject: Re: [CFCDev] MVC File upload

Not to go too far off topic, but I'm not sure I follow this logic. Say you have a stateless method in a service object like:

<cffunction name="processUpload" access="" returntype="void" output="false" roles="" hint="">
    <cfargument name="fieldName" type="string" required="true" hint="" />
    <cfset var local = structNew() />
    <cffile action = ""
           fileField = "#arguments.fieldName#"
        destination = "path and file name"
        result = "local.cfFileResult" />
</cffunction>

What exactly about this is not thread safe? The cffile itself runs only per method call and therefore per thread. The result variable is kept in a method-local variable. I don't see how another user request could have any affect on this.

On 5/11/06, Brian Klaas <[EMAIL PROTECTED]> wrote:
One thing to keep in mind as well is that the CFFILE tag is not thread-safe. This means that data from one CFFILE operation (say, the result data structure from a CFFILE operation) may inadvertently get carried over to another CFFILE operation between user requests if the object that contains the CFFILE code is cached at startup by your MG application. As such, you don't want to instantiate your file upload code in an object that is cached when your MG application starts up. You should instead instantiate a separate object containing the actual CFFILE calls each and every time you need to make a call to CFFILE.

(Another) brian


on 5/11/06 11:03 AM, Brian Kotek at [EMAIL PROTECTED] wrote:

No. I understand how confusing some of these things can be, but in this case I think some additional learning and research is in order. A Data Access Object (DAO) is a very specific kind of object that is part of a design pattern also called "Data Access Object". A DAO is specifically for abstracting database interactions. Handling a file upload is not part of the responsibility of a DAO. For more detail on the DAO pattern, you can Google around, but here is a starting point: http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

I would probably create a FileManager or even a FileUploadManager if the need is very specific, and have this object encapsulate all behavior related to handling a file upload.

Hope that helps! This stuff takes a good long time to wrap your head around (at least it took/is still taking me a long time).

Brian


On 5/11/06, David Henry <[EMAIL PROTECTED]> wrote:

I am very new to the MVC process for web development.  How would I set up a file upload that follows the MVC model?  Should I create a Data Access Object that does cffile operations?  Thanks for your help!

~David
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.


----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

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

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

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

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

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

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting ( www.cfxhosting.com).

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

----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

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

Reply via email to