>> in the example given why do you need a transaction at all? perhaps a bit too simple an example. there's more meaty examples but I can't get to them ATM...
so...in case that, half way thru the transaction, the first table really does get a record returned (ie: someone elses insert beat the delete but the delete doesn't know). Locking the table so the delete happens before anyone sneeks in with an insert will throw a trapable error when the other threads insert runs. the transaction is on one thread. other threads are getting dirty reads of the first table. but they still have access to the table. the only way around that I can see is locking the table or record explicitly or (according to the article you mentioned) have "isolation=serializable" to place all threads accessing this table in a cue (my understanding). we have to manufacture most of our referential integrety and constraints, programing the cascade updates and deletes where needed. In lots of cases, we're re-reading the data to see if any changes have happened and failed the transaction then. Even if this wasn't a legacy db, thinking about what other threads might be doing at the same time has to be considered (this almost relates to another current thread here @cfczone.org). I worry when a trans gets split across multiple actions (eg begin trans on one file, end on another). splitting across multiple methods within a CFC seems to work fine but there's too much to go wrong for anything else. You also have to remember where the trans sits in the call stack. will all methods execute? what if the end trans fails because a page/file/method fails? the question still remains: does anyone explicitly lock (eg: "creatre lock on tableName")? I have NEVER seen an example where people do. will "isolation=serializable" do the same thing? (the article could do with a bit more depth although a good overview) yeah, there's a performance peanelty because of the cuing threads so is there a better way? thanx barry.b -- ___________________________________________________________ Sign-up for Ads Free at Mail.com http://promo.mail.com/adsfreejump.htm ---------------------------------------------------------- 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]
