>> I haven't read your example yet, as I'm scanning messages from newest to oldest, but why would this be a problem?
the first table (for the select) is a look-up "types" table. Only types that do not have addresses assigned to that type can be deleted. As soon as there is another record that assigned to that type, the type can't be deleted. the other side is that another thread wanting to assign an address to a type will check first if the type exists (it won't be there: the thead before deleted the type so throw an error instead). in other words, ref integrety of the db is now encroaching within the code layer. but to get back to the general nature of the question, it looks like either (1) everyone is using SProcs for data integrety, using the db (and not cftransaction) for table and row locking. Damnatation! we can't (a ruling from the boss - portability of code to diff db vendors) - OR - (2) no one is going to this level of data locking and integrity (ie: glossing over what's actually happening and hoping for the best). I say this because associated techniques of re-read before write (to see if another thread has changed the record while it's being edited) or using timestamps (last updated by...) are not commonly covered in listserv posts (yeah, I know lots of people do this or similar but you don't hear much about it). but this gets back to the initial observation that no one is explicitly locking tables or rows. Every method using more than one query needs at least a transaction over them (if they are dependent on each other, that is), and if that's the case, why aren't table and row locks used as well during the transaction? A cftransaction on one thread will NOT stop other threads accessing the tables - it only places restrictions on the thread that it is on (my understanding) >> When you modify a record with any query, that record will be locked for the >> duration of the query. yes, you're 100% right, but that's during the query, not the whole transaction (which is where isolation="SERIALIZABLE" comes in). >> It's my understanding that SERIALIZABLE is the default ISOLATION value for >> CFTRANSACTION in CFMX, is this really the case? the MM article implies otherwise, since it mentions the overhead of serialising (cueing) of the threads and recomends against except in "important" circumstances. To be honest, I thought default cftransaction isolation was optomistic locking... it's a pity that the article didn't have much detail and only gave an overview of isolation="SERIALIZABLE" and mentioned it twice more (re: MSAccess). I really do need to find out what CFTRANSACTION is actually doing under the hood. anyone know? 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]
