I definitely believe this discussion has provided some useful insights into locking!
- Calvin
- Original Message -
From: Dave Watts
To: CF-Talk
Sent: Tuesday, October 28, 2003 1:36 PM
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
> It appears to me that there
> It appears to me that there is/was some confusion over the
> meaning and impact of 'corrupt data'.
I think it's useful to consider data integrity within the relational
database world as a guide. When a transaction is processed, all kinds of bad
things can happen without locking - dirty reads, p
It appears to me that there is/was some confusion over the meaning and impact of 'corrupt data'.
- Calvin
- Original Message -
From: Raymond Camden
To: CF-Talk
Sent: Tuesday, October 28, 2003 11:58 AM
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
Andre,
Java automatically provides it's own internal synchronization to prevent the
variable from being accessed at the exact same time. Two sets to a variable
will always be sequential, it's just a matter of what's second
Sent: Tuesday, October 28, 2003 8:47 AM
> To: CF-Talk
> Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
>
> Ray, i believe what macromedia is refering to is the variable
> being written and overwritten at the same time. Not a
> variable being written, then overwritten aft
Original Message-
> From: Nick de Voil [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 8:46 AM
> To: CF-Talk
> Subject: Re: Scope Locking (RE: Blue Dragon and Fusebox)
>
(snip)
>
> So if you said
>
>
>
> for example, that couldn't cause
> The problem would seem to me to be more severe as indeed
> macromedia has made the statment that you should avoid this
> by spending time to lock the variable.
You are certainly safer if you follow that approach, in the sense that you
no longer have to think about concurrency as much, but I'd
> Ray, i believe what macromedia is refering to is the variable
> being written and overwritten at the same time. Not a
> variable being written, then overwritten after its set.
>
> See the note:
> Race condition is a term that is not specific to ColdFusion
> programming, but refers to a comm
I could well be wrong here, but I think maybe people are being misled by the
statement in the MM doc:
"Simply put, a race condition occurs anytime two threads (in this case, page
requests) try to write to the same data at the same time. "
That doesn't fully describe what's happening in their exam
-Original Message-
From: Raymond Camden [mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 28, 2003 9:31 AM
To: CF-Talk
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
> I'm interpreting your statment that if indeed a race
> condition occurs and that a variable is overwritten at
> I'm interpreting your statment that if indeed a race
> condition occurs and that a variable is overwritten at the
> same time as its being written, that it simply uses the
> second value?? I havent seen anyting to suggest this
> anywhere(do you have more info?).
Well, wouldn't it make sen
PROTECTED]
Sent: Tuesday, October 28, 2003 8:28 AM
To: CF-Talk
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
> In addition, you might have variables which just aren't that
> important. For example, in the official Macromedia
> courseware, race conditions are discussed and a
> In addition, you might have variables which just aren't that
> important. For example, in the official Macromedia
> courseware, race conditions are discussed and an example is
> provided. That example uses a variable to store the number of
> users who have logged into the application. But in
> I think that a number of people don't understand race
> conditions. So tell me, what would you not lock?
Well, not to butt in between you and Sam, but in my experience, most of the
memory variables within an application are unlikely to encounter integrity
issues caused by concurrency (which is
> Sam,
>
> I think that a number of people don't understand race
> conditions. So tell me, what would you not lock?
>
Ok, so I'm not Sam, but I'm going to respond anyway. Is your contention
that since most people don't understand race conditions, then they
should lock everything? If so, that is
Sam,
I think that a number of people don't understand race conditions. So tell me, what would you not lock?
- Calvin
- Original Message -
From: Samuel R. Neff
To: CF-Talk
Sent: Tuesday, October 28, 2003 12:21 PM
Subject: RE: Scope Locking (RE: Blue Dragon and Fu
rom: Calvin Ward [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 5:32 AM
> To: CF-Talk
> Subject: Re: Scope Locking (RE: Blue Dragon and Fusebox)
>
> Sam,
>
> What specifically did you find in my previous email that
> showed lack of understanding on race con
Sam,
What specifically did you find in my previous email that showed lack of understanding on race conditions?
- Calvin
- Original Message -
From: Samuel R. Neff
To: CF-Talk
Sent: Tuesday, October 28, 2003 11:14 AM
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox
s/charting
---
> -Original Message-
> From: Calvin Ward [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, October 28, 2003 1:29 AM
> To: CF-Talk
> Subject: Re: Scope Locking (RE: Blue Dragon and Fusebox)
>
> From the previously referenced pag
But you said locking should always be used. This clearly states that you
should use locks to avoid race conditions, not that you should use it
100% of the time.
[Todays Threads]
[This Message]
[Subscription]
[Fast Unsubscribe]
[User Settings]
8:56 PM
Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
Care to clarify why?
> -Original Message-
> From: Calvin Ward [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 1:09 PM
> To: CF-Talk
> Subject: Re: Scope Locking (RE: Blue Dra
Now THAT I'll agree with. :-)
Sam
> -Original Message-
> From: Jim Davis [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 3:55 PM
> To: CF-Talk
> Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
>
> My opinion is that although you don
g from MX to cf5, or
building for both?
-Ray
> -Original Message-
> From: Samuel R. Neff [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 7:56 PM
> To: CF-Talk
> Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
>
>
> Care to clarify why?
>
>
ilding for both?
-Ray
> -Original Message-
> From: Samuel R. Neff [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 7:56 PM
> To: CF-Talk
> Subject: RE: Scope Locking (RE: Blue Dragon and Fusebox)
>
>
> Care to clarify why?
>
>
> > -
Care to clarify why?
> -Original Message-
> From: Calvin Ward [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 1:09 PM
> To: CF-Talk
> Subject: Re: Scope Locking (RE: Blue Dragon and Fusebox)
>
> I would opine that locking shared scope variables is sti
: Scope Locking (RE: Blue Dragon and Fusebox)
You don't need to lock in MX (or I guess BD) to protect against corruption
or crashing.
You do still need to lock to protect against race conditions.
More info here:
http://www.macromedia.com/support/coldfusion/ts/documents/tn18235.htm
Sam
---
Blog: http://www.rewindlife.com
Charts: http://www.blinex.com/products/charting
---
> -Original Message-
> From: Haggerty, Mike [mailto:[EMAIL PROTECTED]
> Sent: Monday, October 27, 2003 9:53 AM
> To: CF-Talk
> Subject: Sco
On Monday 27 Oct 2003 17:53 pm, Haggerty, Mike wrote:
> Does this mean locking the application scope is unnecessary in CFMX &
> BD, even when setting values? Or am I just misunderstanding your
> comments.
In previous CF versions, not locking would run the risk of crashing your
server, as memory c
Matt -
I wanted to confirm what you mean when you say 'the application scope is
now automatically synchronized'.
Does this mean locking the application scope is unnecessary in CFMX &
BD, even when setting values? Or am I just misunderstanding your
comments.
M
-Original Message-
From: M
29 matches
Mail list logo