Probably isn't the best way, but it seemed like the path of least resistance at the time :) Unfortunately in the process it seems I uncovered something strange going on under the hood in CF. With all the information about locking out there, nothing has ever been written about cflock having side effects on totally separate threads with no locking routines that I have seen. That is exactly what I am seeing now though.
-- jon mailto:[EMAIL PROTECTED] Monday, September 23, 2002, 3:11:18 PM, you wrote: MAKC> Jon, MAKC> Perhaps I'm missing something and this is an entirely new and clever MAKC> approach. I've never tried to use CFLOCK as a timeing mechanism. But what MAKC> you are doing here with your named locks seems like intentionally hanging MAKC> the process - something I usually tried to avoid doing by accident <g>. Do MAKC> many developers use this approach? Are you sure this is the best way to go MAKC> about creating execution time in your process? MAKC> -mk MAKC> -----Original Message----- MAKC> From: jon hall [mailto:[EMAIL PROTECTED]] MAKC> Sent: Monday, September 23, 2002 1:58 PM MAKC> To: CF-Talk MAKC> Subject: Strange threading issue, cflock? MAKC> Another locking question...might be a bug in CF5. MAKC> Using CF5, I have a database insert that I need to pause a few MAKC> seconds, then select a value back out that is updated from withing MAKC> the db. My code looks something like this: MAKC> <cfquery .../> // Insert Query MAKC> <cfset name = Hash(CreateUUID())/> MAKC> <cflock name="#name#" type="readonly" timeout="1"> MAKC> <cflock name="#name#" type="exclusive" timeout="5" throwontimeout="No">></cflock> MAKC> </cflock> MAKC> <cfquery .../> // Select Query MAKC> What is strange is that the second query is not executing after the MAKC> cflock times out. It seems that it must be executing _before_ the MAKC> cflock starts! The database usually takes about 1 second to update MAKC> the field, and even if I set the timeout to 20 seconds the recordset MAKC> returned always contains data that would indicate that the query MAKC> didn't wait until the cflock timed out, but executed before the MAKC> cflock... MAKC> It gets stranger even. If I set the timeout high enough and try to MAKC> execute a second page with only the bottom query from above at the MAKC> same time I am executing the above cfquery/cflock/cfquery block the MAKC> single cfquery on a totally different page waits for the lock to MAKC> execute, even though it has no cflocks anywhere in it! The rest of MAKC> the site continues to operate normally, with CF executing pages, but MAKC> it's like this particular cfquery block is respecting the cflock in MAKC> the other page, even though it's not in a cflock itself. MAKC> To even futher the proof, I have two databases, a primary and a MAKC> backup that I can perform the same two queries against. The second MAKC> page with the query by itself queried using the other DSN, executes MAKC> instantly! Only when I use the same DSN does this page stop MAKC> everything it is doing to wait for the second one to execute. MAKC> All of this seems to contradict what I know about how CF uses locks. MAKC> I think it's a bug with cflock...and a nasty one. Anyone know what MAKC> may be going on? MAKC> -- MAKC> jon MAKC> mailto:[EMAIL PROTECTED] MAKC> ______________________________________________________________________ Get the mailserver that powers this list at http://www.coolfusion.com FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
