The appropriate use of locks can be really important. Here's a case in
point that cost me a LOT:
I did an application for a client where to save processing time, I put a
couple of variables used many times into the application scope. In this
case I wasnt allowed to deploy the application to t
Klaatu Verata Nicto
;)
larry
>> Are you and Barney speaking English?
>
>Nanu nanu :)
>--
>Sean A Corfield -- (904) 302-SEAN
>Railo Technologies, Inc. -- http://getrailo.com/
>An Architect's View -- http://corfield.org/
>
>"If you're not annoying somebody, you're not really alive."
>-- Margaret
On Mon, May 31, 2010 at 11:56 AM, Barney Boisvert wrote:
> "locks aren't necessary for simple reads" to prevent memory
> corruption. They ARE necessary if you have a potential race
> condition.
It's also worth noting that whether you need to lock or not depends on
the type of data being shared
"locks aren't necessary for simple reads" to prevent memory
corruption. They ARE necessary if you have a potential race
condition.
To put that another way, CF5 and before required locks to prevent
memory corruption, but CF6+ does not. However, if you care about your
application behaving correct
On Sun, May 30, 2010 at 7:41 PM, andy matthews wrote:
> Are you and Barney speaking English?
Nanu nanu :)
--
Sean A Corfield -- (904) 302-SEAN
Railo Technologies, Inc. -- http://getrailo.com/
An Architect's View -- http://corfield.org/
"If you're not annoying somebody, you're not really alive.
ve Watts [mailto:dwa...@figleaf.com]
Sent: Monday, May 31, 2010 9:59 AM
To: cf-talk
Subject: Re: referencing #application.applicationname#
> Are you and Barney speaking English?
I suspect this is just a joke on your part, and I'm not really
addressing this response to you specifically. But the reas
> Are you and Barney speaking English?
I suspect this is just a joke on your part, and I'm not really
addressing this response to you specifically. But the reason I'm still
on this list is mostly people like Barney and Sean. When I read their
posts, I'm likely to learn something I didn't know bef
Do you remember what chapter that is? I'm 99% sure CFWACK makes it
clear that locks aren't necessary for simple reads. I remember writing
those updates myself a few revs back but I'd like to confirm the
current text is clear.
On Sun, May 30, 2010 at 4:29 PM, Matthew P. Smith
wrote:
>
> Does th
> Does this require a lock?
>
> I was reading through the CF WACK, and it has an example like so:
> timeout="10">
>
> does reading the app scope require a lock? Would I nest two locks? Or is
> it not required because the application name does not change?
Barney's response - specifically his fi
Are you and Barney speaking English?
-Original Message-
From: Barney Boisvert [mailto:bboisv...@gmail.com]
Sent: Sunday, May 30, 2010 4:39 PM
To: cf-talk
Subject: Re: referencing #application.applicationname#
CFLOCK is only required to serialize access to prevent race
conditions. For
On Sun, May 30, 2010 at 2:39 PM, Barney Boisvert wrote:
> This purity of environment only works completely in academia, but a
> very close approximation can be created that is useful for real-world
> problems. Clojure (a JVM-based Lisp dialect) is an example of this,
> leveraging Actors to deal
CFLOCK is only required to serialize access to prevent race
conditions. For immutable state, no race conditions can arise, so
locking is unneeded. Since application.applicationname is immutable,
you don't need to lock access to it.
In a more general sense, anything that is only accessed in a re
Does this require a lock?
I was reading through the CF WACK, and it has an example like so:
does reading the app scope require a lock? Would I nest two locks? Or is
it not required because the application name does not change?
13 matches
Mail list logo
