Point taken about my emphasis on frames, I was trying to be witty is all.

I’m sending the messages to file instead of screen, so I can see what order they’re in, and – as Ruud alluded to – the inner “globallockthatbreaks” clears the “outer” one too. Although it’s got nothing to do with the “empty” tag: I would never run code with poorly-formed CFML tags, so expanded it out and added a message within the lock, and one still gets what you’re seeing.

Note that if the INNER “globallockthatbreaks” is readonly, not exclusive, then the issue does not occur.

I’m not sure this is a bug though, as I can’t find any reference to being able to nest locks. Although equally, I can’t see anything that one CAN’T either.

Bug or not: it’s good to know about.

Cheers.

–
Adam

Amazing how simple it is to completely bust the CFLOCK tag. First, you create a simple page that has FRAMES and loads another page into each FRAME.”
(my emphasis)

Are you telling me you’re NOT suggesting frames have something to do with it, given your statements above?

–
Adam

Ruud, funny how me seeing the results is not a mystery when you don’t see them :)

Adam, thanks for the input, but the premise isn’t faulty. You’re right that the frames are irrelevant, I simply chose that for simplicity. What I’m pointing out is that I’m seeing a GLOBAL lock not being honored. I doesn’t matter how the two requests are generated, the GLOBAL lock should be honored.

I’ll upgrade to 7.0.2 and test again.

And – as Ruud says – it works fine for me (7.0.2.142559).

The premise itself is a bit faulty anyhow: CF has no way of knowing that these two requests are in frames, it just sees two requests. So the fact the two requests are being called from frames is irrelevant to anything you might experience, one way or the other.

–
Adam

Having said that, however, when I run the code, using CFMX 7.0.2, the lock is honored just fine. What version are you using?