> 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 whe
@ 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 almo
@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
>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.
On Mon, Jun 1, 2009 at 16:59, Jay Greer 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, could
@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
@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?
> 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 e
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
>
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
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:
(timeout can be whatever is appropriate)
~|
Want to reach the ColdFusion community
> 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
> --
>
>
It depends.
What version of CF is this?
Is there any likelihood of a race co
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
--
~|
Want to reach the Col
13 matches
Mail list logo
