Subject: Re: CFLOCK problem
Well, I guess is there are exclusive server scope locks like this one
all over the place, you are basically single threading the entire
server in multiple points, including all apps. Under the right load I
suppose that could slow things down enough to start queueing threads
I would argue that that is not only a horrible abuse (LOCKING on SEVER to
set something in SESSION), but that this situation doesn't even need a lock
at all. The race condition here seems unimportant. In fact, it is locking
for one CFSET but not the other. Get rid of this lock.
I would argue that that is not only a horrible abuse (LOCKING
on SEVER to set something in SESSION), but that this
situation doesn't even need a lock at all. The race condition
here seems unimportant. In fact, it is locking for one CFSET
but not the other. Get rid of this lock.
Not to
I would argue that that is not only a horrible abuse (LOCKING on SEVER to
set something in SESSION), but that this situation doesn't even need a lock
at all.
That's assuming that the server is CFMX, not CF5 (which the OP didn't specify),
otherwise a lock is indeed needed. Pretty awful code
Sorry guys. We are using CF MX 7.
So, do we agree that this code does not need the locking, and also
that this code has the power to crash a CF server under high traffic?
Please let me know.
Thanks,
K
On 8/31/06, Mary Jo Sminkey [EMAIL PROTECTED] wrote:
I would argue that that is not only a
That code is the same as:
cfparam name=textfield default= /
cfparam name=session.ord default=#textfield# /
and as others have pointed out, locking isn't required for this case in CFMX.
-Cameron
On 8/31/06, Ken [EMAIL PROTECTED] wrote:
Hi. I am analyzing another programmers code for possible
That code doesn't have the power to crash anything, it's just dumb code.
-Cameron
On 8/31/06, Ken [EMAIL PROTECTED] wrote:
Sorry guys. We are using CF MX 7.
So, do we agree that this code does not need the locking, and also
that this code has the power to crash a CF server under high
That code doesn't have the power to crash anything, it's just dumb code.
Are you sure? I'm wondering what that really long timeout is going to do. If
for any reason a thread isn't able to obtain a lock, it's going to be waiting a
*very* long time before timing out. I agree it's unlikely, but
Well, I guess is there are exclusive server scope locks like this one
all over the place, you are basically single threading the entire
server in multiple points, including all apps. Under the right load I
suppose that could slow things down enough to start queueing threads
and bring the server
9 matches
Mail list logo
