Webmaster Forum / ColdFusion / Advanced Techniques / September 2007

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?

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.

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.

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?

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

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.

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!!!

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!