> You've hit it pretty much on the head. > > As an example let's say you call the "Delete" method of a > CFC and that CFC, in turn, calls the "delete" method for > two linked children. > > It would be nice (I think) to abstract the DB transaction > into the CFCs (or into persistence components called by them > or whatever - but away from the implementation interface) > but that's not as easy as it sounds at first glance. > > It's not really so much about using them in the same page - > you can have a beginning transaction one CFC and an ending > in another - this seems to be dealt with at the request level. > Rather it's about starting one in a method in an instance of > component then called the same method on a different instance > (as in the example above) as would be done during recursive > calls. > > At least that was my issue. I've since "solved" it such that > it works but I hate the implementation. I'd love to find an > elegant way to deal with this.
I don't have a solution you'll like - my solution is simply to place all transactional logic within the database. In my opinion, that's usually where it belongs, rather than in the business logic at all. But of course, that's not really a solution to your problem, just a perspective that doesn't acknowledge the problem in the first place. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [EMAIL PROTECTED] with the words '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]
