Cody's approach is definitely good. If you are using an application architecture that uses a Service layer along with DAOs, it is usually easiest to make all of your DAOs unaware of any transactional context and apply transaction behavior within your Service's methods. So all of your DAO methods would simply perform the necessary database operations without a CFTRANSACTION tag. Then in your service method, you can wrap several DAO method calls with a CFTRANSACTION and apply the desired transactional behavior there.
In the Java world you can use Spring to dynamically apply transactional behavior to a Service object's methods using AOP. If you are familiar at all with AOP or have looked at ColdSpring you could probably implement something similar by using an "around" join point (i.e, you are applying behavior around a method, by "wrapping" it in a CFTRANSACTION tag). This is nice since the transactional behavior isn't "baked" right into your Service's code and can be modified just by tweaking an XML file. Anyone know if ColdSpring supports this out of the box? -Cliff On 3/16/06, Jason Daiger <[EMAIL PROTECTED]> wrote: > I do the exact same thing. If a CFC it's told to start a transaction, any > save calls that CFC makes to other CFC's tell them to not start a > transaction thus preserving the 1 big transaction chain. Since all my DAO > CFC's have the exact same interface it makes it very easy to manage. > > > Aaron Rouse wrote: > Lately, what I do is I have something like InsertMyRecord() that has two > arguments one being a structure of data to insert and the other a flag for > if it is going to need to be in a transaction. Then within it I call a > private method that actually does the inserting and depending on that > transaction flag the call to my private inserting is either wrapped in a > transaction or not. > > On 3/16/06, Michael T. Tangorre <[EMAIL PROTECTED]> wrote: > > I have seen this issue pop up from time to time on this list and thought I > > would inquire as to how people are handling this... > > > > What are some of the options when it comes to using transactions, > > committing, and rolling back when the pieces of the transaction come from > a > > variety of CFCs? > > > > Thanks, > > > > Tango. > > > > > > > > > > > ---------------------------------------------------------- > > 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] > > > > > > > > > > -- > Aaron Rouse > http://www.happyhacker.com/ > ---------------------------------------------------------- > 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] > -- Jason Daiger URL: www.jdaiger.com EML: [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]
