Barry, I was on your side, I thought the response was a bit ruff, while you were merely trying to help.
I reckon its because this list is so open, and everyone can read the responses, it can sometimes make someone feel like "Oooh I don't want anybody else to read I didn't know about that"... Or "I already know about that, but now it looks like I did not know about it".. I must admit I sometimes feel like that and want to give a response like "I already knew that, so don't make me look like a fool". But I don't care anymore, the more you can write in the email the more other people learn. Go Barry go.... Taco Fleur Tell me and I will forget Show me and I will remember Teach me and I will learn > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Barry Beattie > Sent: Thursday, 29 July 2004 2:51 PM > To: CFAussie Mailing List > Subject: [cfaussie] RE: CFTransaction and CFC's > > > > >> trying to help people without properly reading their emails? > > well, it depends on your point of view, Taco... > > >> I have a loop within a cftransaction that will call > another cfc (this > is the idea anyway) > > so I waxed lyrical about how external CFC's within a > cftransaction need to be handled. > > >> Is it possible to call another function > > yeah, that too > > >> and expect the calling function's cftransaction to handle > commit and > rollback of errors provided by other functions, provided it > is within a cftry block? > > well I must admit I didn't get that bit. It sounded like > nested cftransactions (the second in the called method) but > no one would be mad enough to nest multiple transactions like > that OR it could be that the called method deliberatly threw > an error (which would cause the transaction to fail so the > whole lot would rollback) so I glossed over that bit, waiting > for clarification/specifics. > > >> > Function() > { > try > { > cftransaction > CheckExistance(); > InsertInformation(); > /cftransaction > } > catch (e) > { > ....error handling > } > } > > I'm sorry to say that that pseudocode was not as clear as the later > example: > > <cftry> > ...more logic removed > <cftransaction> > <cfloop index="Count" from="1" to="3"> > ..more logic removed > <cfset InsertData(stufftoinsert) /> > </cfloop> > </cftransaction> > </cftry> > <cfcatch> > </cfcatch> > > and then it moved on to serializable or not then using > @@identity, etc, and the rest is history. > > In the end it'll probably end up working fine with just a > <cftransaction isolation=serializable> with no try/catch at > all (just a <cfthrow> in the called method) but there wasn't > a wealth of info to work on. > > Taco, I felt sorry for the guy because I've been trying to > nail exactly how cftransaction works. Yeah, there's a lot of > info in the replies but that's partly so some other poor > bastard has a fighting chance when they're struggling with > cftransaction too! > > Andrew has a hundred things to consider in designing his > system to maintain data integrity. sure the solution might > end up being simple but there's more to it than meets the eye. > > I mean I (and others) have asked curly CFTRANSACTION > questions and have had bugger all responses (just go through > the semi-recent cfaussie archives). > > Either no one knows or no one cares. All I was doing was > trying to help out. I mean, no one has else bothered to > answer his specific question, have they? (I did ask for > others to chime in, yes?). If the thread was drifting away > from the origional intent, then it could easily be clarified. > > Taco, feel free to come in and answer Andrew's specific > question. As I said earlier, I'm reasonlably sure that it'll > work fine with a <cftransaction isolation=serializable> with > just a <cfthrow> in the external called method - but the only > way to really prove it is to code it up and place it under > load. I don't have any working code doing this > - do you? (and if you do please feel free to chime in...) > > At least it's given me an insight into how Sean C and Spike > must feel some days when they're only trying to help... > > oh well, them's the breaks... > > > > > > > > > > > > > > > > > -----Original Message----- > From: Taco Fleur [mailto:[EMAIL PROTECTED] > Sent: Thursday, 29 July 2004 1:51 PM > To: CFAussie Mailing List > Subject: [cfaussie] RE: CFTransaction and CFC's > > > barry have you been a bad boy again, and trying to help > people without properly reading their emails? > > bad bad boy... > > -----Original Message----- > From: And;-)rew Scott [mailto:[EMAIL PROTECTED] > Sent: Thursday, 29 July 2004 1:45 PM > To: CFAu;-)ssie Mailing List > Subject: [cfaussie] RE: CFTransaction and CFC's > > > Bar;-)ry, > > But that;-) is what I am doing, did I not sa;-)y that in my > fir;-)st email? > > > <cftry> > ...more logic re;-)moved > <cftrans;-)action> > <cfloop index="Count" from="1" to="3"> > ..more logi;-)c removed > <cfset Ins;-)ertData(stufftoinsert) /> > </cfloop> > </cft;-)ransaction> > </cftry> > <cfcatch> > </cfcatch> > > I was well ;-)aware of not ;-)doing the old, commit, begin > and ro;-)llback and wasn't even needing any adv;-)ice on that!! > > Gosh, I wish peop;-)le would actually read emails!! > > > > Regards > And;-)rew Scott > Technical Consultant > > NuSphere Pty Ltd > Level 2/33 ;-)Bank Street > South Melbourne, Victoria, 3205 > > Phone: 03 9686 0485 - Fax: 03 9699 7976 > > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf > Of Barry Beattie > Sent: Thursday, 29 July 2004 1:38 PM > To: CFAussie Mailing List > Subject: [cfaussie] RE: CFTransaction and CFC's > > >> the point is that I use the cftransaction because there is > a loop of > > >> 3 inserts and if one fails they all need to fail > > from a thread I started on cfczone.org > http://www.mail-archive.com/[EMAIL PROTECTED]/msg05876.html <snip> > Dave, I noticed (in a houseoffusion post) you shy away from try/catch > within a transaction. how come? It's usually not necessary, especially within the commonly used example that is posted over and over again, in which an exception is thrown and caught within the CFTRANSACTION. If you have multiple queries using the same database connection within a CFTRANSACTION, and one of them fails, there's no need to catch that failure and issue a rollback, as the CFTRANSACTION tag will do that for you </snip> hope that helps barry.b --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ Register now for the 3rd National Conference on Tourism Futures, being held in Townsville, North Queensland 4-7 August - www.tq.com.au/tfconf --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/ --- You are currently subscribed to cfaussie as: [EMAIL PROTECTED] To unsubscribe send a blank email to [EMAIL PROTECTED] Aussie Macromedia Developers: http://lists.daemon.com.au/
