Acknowledged. My (admittedly conservative) approach is to prove that the app
_doesn't_ need locking rather than the reverse. Don't get me wrong, I'm all
in favour of
eliminating both the extra coding burden as well as the overhead. That said,
the docs
seem to lean towards locking when in
Having a brain cramp on this one guys...
How would one approach locking when reading a value from the APPLICATION
scope and subsequently writing it to the SESSION scope..?
EXAMPLE
--
cfset session.foo = application.bar
It depends.
What version of CF is this?
Is there
Assuming you're on CFMX 7 or 8, you no longer need to LOCK on READ, so if
you're concerned about race conditions on the WRITE, just do:
cflock scope=session type=EXCLUSIVE timeout=10
cfset session.foo = application.bar
/cflock
(timeout can be whatever is appropriate)
Is there any reason you can't simply lock the app scope, grab
application variable and put it into a local variable, unlock, lock
session, copy from local var to session var, unlock?
~|
Want to reach the ColdFusion community
That would work, but it's unnecessary overhead unless you're still on CF 5.
Virtually all that locking has been handled in MX.
~|
Want to reach the ColdFusion community with something they want? Let them know
on the House
That would work, but it's unnecessary overhead unless you're still on CF 5.
Virtually all that locking has been handled in MX.
Well, no, that's actually not correct. CF doesn't lock variables
unless you use CFLOCK. It simply doesn't crash if you don't lock them,
as it used to with CF 5 and
@Dave
What version of CF is this?
CF-8.1
Is there any likelihood of a race condition with Application.bar?
It's possible, yes.
If there is the likelihood of a race condition with that variable, do
I care? That is, could the race condition cause an improper value of
any significance?
@Jason
Assuming you're on CFMX 7 or 8, you no longer need to LOCK on READ...
Well that's debatable for sure...
http://www.horwith.com/index.cfm/2008/4/28/cflock-explained
http://www.horwith.com/index.cfm/2008/7/17/CFLOCK-further-explained
On Mon, Jun 1, 2009 at 16:59, Jay Greer m...@gobluerocket.com wrote:
@Dave
What version of CF is this?
CF-8.1
Is there any likelihood of a race condition with Application.bar?
It's possible, yes.
If there is the likelihood of a race condition with that variable, do
I care? That is,
Then lock the application scope with a read-only lock, copy the value
into a local variable, then lock the session scope with an exclusive
lock, then copy the local variable into the session.
Roger that...
Thanks, Dave all.
@Jay
Yes, fair enough. Granted that CF doesn't guarantee the order of
execution when processing threads in a request, does the application in
this case really have the possibility of having multiple threads making
sequential changes to that specific session variable (which is
thread-safe to
@ Jason
Are there Ajax or iframe calls or something that could be making
updates to that session var for that user at the same time in a
situation where the order of execution could cause an unexpected value
to be read back out by the server?
Yup...
To me, it just seems that you almost
12 matches
Mail list logo
