>> . who's responsible to lock: the enabler or the enabler's client? I can see both sides of the issue...
aye, so can I and that's the problem...I even flirted with the idea of the view doing the lock (but that's just wrong!) it all stems back to having a view-centric system where it's a request for a file that sets the lock. and as I said, it's not as sophisicated as having db connection pooling to cue access (where the whole problem is shoved off to the db driver and db engine...) Jared, I like your enabler idea. I'm hoping to have the whole thing abstracted enough that you don't know (or care) you're getting XML data - the DAO just gets "data" and how is hidden elsewhere. thanx all for the input cheers barry.b On 4/27/05, Jared Rypka-Hauer - CMG, LLC <[EMAIL PROTECTED]> wrote: > Sorry, Barry... apparently I misunderstood the question. > > I'd still recommend using a file-system enabler and putting the > file-system locking in that enabler, not in your DAO. > > Then again, this is a big debate... who's responsible to lock: the > enabler or the enabler's client? I can see both sides of the issue... > but really, it's the enabler's job to deal with the file system, and I > think that includes locking. Besides that, anything using the enabler > is going to need the locks, so I'd also say that code duplication is > lessened by locking not within the DAO but within the enabler. > > The Tartan HelloWorld sample app uses an XML file as a datasource for > a DAO... it's read-only and doesn't use locking, but it does exist. > It's going to need to use a file-system extension unless you're going > to embed cffile tags in the DAO itself, so you're still back to using > a file-system enabler, which, again, I'd lock internally so that the > write() method simply *is* locked. > > Laterz, > J > > On 4/26/05, Barry Beattie <[EMAIL PROTECTED]> wrote: > > 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 > > -- > --------------- > ------------------------------------- > Buy SQLSurveyor! > http://www.web-relevant.com/sqlsurveyor > Never make your developers open Enterprise Manager again. > > > ---------------------------------------------------------- > 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]
