cflock timeouts

[nottim22]

When I want to lock a session against itself I use something like:
<cflock name="session#session.CFToken#" type=exclusive timeout=10>
[ which one assumes is logically equivalent to <cflock scope=session type=exclusive timeout=10>]

So assuming a user doesn't access multiple pages simultaneously (and assuming it takes less than 10 seconds per page), this should never time out.

However, sometimes when I have a scheduled task running 10-20 user sessions timeout at once stating that the cflock is the problem.

Anyone have any thoughts? Either the error location it's giving is wrong of there's some kind of uberlock being implicitly executed somewhere (since the scheduled task does not do a cflock).
Thanks!
Tim

[Grizzly9279]

Are the <cflock>'s in question surrounding code that access some shared resource (other than the session scope?) E.g...the database, the application scope, files on the file system, etc.

If so, is the scheduled task in question accessing any of those same shared resources?

[nottim22]

Yes. It's accessing database resources. And since it's the expensive nightly cleanup that's causing the problem...

I had assumed that the timeout parameter meant how long something would block at the cflock before throwing an error.

But it sounds like you might be saying that it means the maximum amount of time you can spend inside a cflock before an error is thrown. And further that when the error is thrown it's thrown by the cflock rather than the particular statement within the cflock where time ran out?

That'd be odd since the text of the error is "A timeout occurred while attempting to lock <lock name>" which sounds like it's waiting to get the lock at the time the error occurs.

[nottim22]

Rechecked the docs. They say the timeout is the time to wait to obtain the lock. It has, therefore, no knowledge of what's going to happen once it gets inside the lock.

So I'm back to not understanding how it can block at the cflock for 10 seconds when no one else is issuing a cflock on the same name - unless, of course, there is some process that can consume all reseources for 10 seconds and let no other processes execute. One would assume that executing a cflock on a name where there is guaranteed to be no other lock on that name would be virtually instantaneous.

[Grizzly9279 · Accepted solution]

Is it possible that your original assumption that:

"...a user doesn't access multiple pages simultaneously"

is incorrect? I could imagine a scenario where a single user enters a lock named "session#session.CFToken#", which makes a long slow call to the database. If that user gets fed up waiting, and hits stop/refresh in their browser, it is possible that their original request thread is still being processed, so the second request thread which again uses the lock name "session#session.CFToken#", waits more than 10 seconds for the first lock to "free up", and then throws an error.

Is there any way you can dig into your web server logs to see if this is indeed the behavior that is taking place around the time that these lock timeout errors occcur?

[Newsgroup_User]

> When I want to lock a session against itself I use something like:
> <cflock name="session#session.CFToken#" type=exclusive timeout=10>
> [ which one assumes is logically equivalent to <cflock scope=session
> type=exclusive timeout=10>]

Out of interest, why AREN'T you just locking the session scope, instead
trying to emulate it with a named lock.

--
Adam

[nottim22]

Locking the entire session scope is not sufficiently fine grained.

Suppose you have two variables session.x and session.y and from time to time you increment them.

You COULD lock the session scope around any increment, but then an increment of session.y could be held off if you are incrementing session.x. So locking either "incrementx#session.CFToken#" or "incrementy#session.CFToken#" would avoid that.

Of course, if all you were doing was an increment of a session variable you could lock the whole session. But if you're doing something more time consuming then having independent locks will result in fewer waits. That assumes, of course, that the set of variables updated in each lock is in fact independent.

[nottim22]

Grizzly, I think you're right. I woke up this morning and realized that the methodology I was using to prove that the user wasn't just doing something like you propose was flawed.

So I'll fix that and I bet I'll discover that that's what's happening.

Of course, the real solution is to find the long running query that I'm executing during clean up and make it run faster or break it up into parts and execute a portion of it every hour to avoid locking up users.
Thanks!!!

[Grizzly9279]

You're absolutely correct, the right fix here would be to speed up the eliminiate the scheduled process that is locking up the database like that.

Anyways, I'm glad I could help you think it through...best of luck with it!