Can I ask: why not just build a CFC layer that exposes a simple API that does the transaction internally, then have that layer make use of your underlying persistence mechanism? That is, why make an end-developer have to even think about transactions if they are a known quantity in advance? Instead, just build one or more CFCs that are the "business layer" and then let the developer use those. So, for instance, if you have a persister with methods like:
insertUser(id,fname,lname,email); associateUserWithDepartment(userID,deptID); associateUserAsDirectReport(userID,bossID); and you have a transaction, which will be "insert a user and associate him/her with a given department and make them a direct a report of another given user" you can have your persister layer expose a granular API that is transaction agnostic, then build a UserManager.cfc (or whatever) that has a method like: saveUser(user,deptID,directReportID); Your saveUser method can then call the methods of the persister in a transaction. I am no OO expert, but in my experience thus far with CFCs I find it's generally best to not have the end-developer interact directly with a persistence layer in anything other than the simplest systems, preferring instead to encapsulate that complexity with a higher-order API. Or, am I missing the boat here? - Nathan > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Behalf Of Barney Boisvert > Sent: Tuesday, November 18, 2003 1:47 PM > To: [EMAIL PROTECTED] > Subject: RE: [CFCDev] cftransactions in low level modules > > > I'm not sure I have an answer to that one, as you're kind of mixing > different styles. I think I'd still say that a transaction can only be > controlled from the upper level, outside the function, so you'd > need to add > CFTRANSACTION tags around the first CFINVOKE, just like the second set. > > Here's another idea: > > This is totally shooting from the hip (with code below), but what about > making beginTransaction, rollbackTransaction and > commitTransaction functions > in your CFC. Inside the function body, they'd use a > request-scoped flag to > track whether there is a transaction currently open, and would > only actually > do anything when the state changed. Then you would call them from inside > your functions (taking care of case one), and you could also call > them from > outside the functions (case two), in which case the inside calls > wouldn't do > anything, because there is already a transaction in progress. > > function beginTransaction() { > if (request.transactionNext EQ 0) { > CFTRANSACTION ACTION="begin" > } > request.transactionNext = request.transactionNext + 1; > } > > function rollbackTransaction() { > if (request.transactionNext EQ 0) { > CFTHROW TYPE="NoValidTransactionException" > } > CFTRANSACTION ACTION="rollback" > request.transactionNext = 0; > } > > function commitTransaction() { > request.transactionNext = request.transactionNext - 1; > if (request.transactionNext EQ 0) { > CFTRANSACTION ACTION="commit" > } > } > > > -----Original Message----- > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > > Behalf Of Jay Gibb > > Sent: Tuesday, November 18, 2003 12:34 PM > > To: [EMAIL PROTECTED] > > Subject: RE: [CFCDev] cftransactions in low level modules > > > > > > Hey Barney, > > > > What about if you're not using OO modelling? This is for a procedural > > system. A pseudo implementation might be... > > > > <!--- in one place... ---> > > <cfinvoke method="myFunction" component="myComponent" > > returnVariable="result"> > > > > <!--- in another place... ---> > > <cftransaction> > > <cfinvoke method="myFunction" component="myComponent" > > useTransaction="no" > > returnVariable="result"> > > > > <cfinvoke method="myFunction" component="myComponent" > > useTransaction="no" > > returnVariable="result"> > > > > <cfinvoke method="myFunction" component="myComponent" > > useTransaction="no" > > returnVariable="result"> > > </cftransaction> > > > > - j. > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email > to [EMAIL PROTECTED] with the word '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] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the word '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]
