As long as you use a named lock around the file operations, I don't know why
it would cause any issues:

<cflock name="#fullPathToTheFile#" type="exclusive" timeout="30">
        <cffile action="doSomething" .../>
</cflock>

Roland

-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Barry Beattie
Sent: Tuesday, April 26, 2005 6:47 PM
To: [email protected]
Subject: [CFCDev] Re: cffile/cfdirectory within a DAO

so no one has used XML files as a data source within DAO's ? 

I just need to confirm that locking for file access (read, write,
delete) is kosher within a cfc and that there's nothing I've missed...


cheers
barry.b


On 4/27/05, Barry Beattie <[EMAIL PROTECTED]> wrote:
> hi all
> 
> I'm just about to add xml functionality using cffile, cfdirectory to
> the persist layer. (each persist decorates it's service which
> decorates a singleton in server scope). The files are on the
> webserver, not uploaded.
> 
> this is sort of the idea (but the thread petered out...)
> http://www.mail-archive.com/[email protected]/msg06983.html
> 
> But since CFFILE is a global scope like URL, FORM, or REQUEST (and we
> don't break encapsulation by accessing external scopes within a CFC),
> I'm a bit unsure if this is actually a good idea.
> 
> also, none of the cfc's (so far) access the filesystem directly - and
> I'm quite happy about that, especially when it comes to file locking,
> etc. If it's database access the persist needs then the db connection
> pool will take care of db access - but what about file access in this
> case? If any locking is done, it's done at the UI/view layer - there's
> no locks within CFC's
> 
> any suggestions, etc?
> thanx
> barry.b
> 
> === persist.cfc ===
> getAllXmlFiles(path)
> getXmlFile(filename, path)
> setXmlFile(filename, path)
> deleteXmlFile(filename, path)
>


----------------------------------------------------------
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