> 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.
I haven't read your example yet, as I'm scanning messages from newest to oldest, but why would this be a problem? That is, why do you want to prevent anyone from inserting a record while you're deleting another record? In general, this capability isn't a bad thing. > 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). When you modify a record with any query, that record will be locked for the duration of the query. Depending on your database and its configuration and default locking granularity, more records may be locked as well - perhaps records within the same leaf or page, or as in MS Access for example, the entire table. If that's all you want, there's no need to use a CFTRANSACTION around one query. > will "isolation=serializable" do the same thing? (the article > could do with a bit more depth although a good overview) This will lock any resources used by the transaction (as determined by the database and its locking granularity) for the duration of the transaction, and will cause the transaction to fail if it encounters any locks. It's my understanding that SERIALIZABLE is the default ISOLATION value for CFTRANSACTION in CFMX, although I don't think it used to be. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: 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]
