practice or should I just remove the locks?
-Original Message-
From: charles arehart [mailto:[EMAIL PROTECTED]
Sent: 31 October 2005 22:24
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
Andy, the problem isn't with duplicating sessions, per se, and it's not a
..NET issue. There is a bug
Did you ever get a solution to this? I too am having the same problem with a
fusebox 4.1 app running on Bluedragon 6.2 .NET that is choking when trying to
execute the following code
cfset request.session = duplicate(session)
It just seems to be a problem with the 'duplicate' function?
Okay,
Did you ever get a solution to this? I too am having the same problem with a
fusebox 4.1 app running on Bluedragon 6.2 .NET that is choking when trying to
execute the following code
cfset request.session = duplicate(session)
It just seems to be a problem with the 'duplicate' function?
]
Sent: 31 October 2005 17:38
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
Did you ever get a solution to this? I too am having the same problem with a
fusebox 4.1 app running on Bluedragon 6.2 .NET that is choking when trying
to execute the following code
cfset request.session = duplicate
'. Do we have any Bluedragon guru's on this forum who could help
me out with a number of issues that I have with trying to migrate to
Bluedragon?
-Original Message-
From: Andy Mcshane [mailto:[EMAIL PROTECTED]
Sent: 31 October 2005 17:38
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
BTW, I should have answered how I found out about the note. I have a google
alert set to tell me of anything it finds anew for BlueDragon, and since this
list is tracked by google groups, it notified me.
The mechanism is spotty, and I can't rely on it always pointing out such notes
to me, and
Geez Mike...
Wasn't sure if or how to respond.
Each seem equally audacious:
1. Any statement that BlueDragon is the official
upgrade version of ColdFusion Server
2. That such a statement could be related to any
marketing message, literature or discussion
by anyone directly affiliated with
Thanks Ken. Here's to hoping!
Both responses should cover the gamut
of possible interpretations.
-Original Message-
From: Ken Wilson [mailto:[EMAIL PROTECTED]
Sent: Wednesday, October 29, 2003 12:16 PM
To: CF-Talk
Subject: Re:Blue Dragon and Fusebox
For what it's worth, when I read
. Neff
To: CF-Talk
Sent: Monday, October 27, 2003 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
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]
---
-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 page:
http://www.macromedia.com/support
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)
So you're
[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 conditions?
- Calvin
[Todays Threads
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 Fusebox)
Calvin, I'm
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 a
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
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 real
, 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 an example is
provided. That example uses
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 sense that
data.
see where it says corrupt data?
DRE
-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
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
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 common issue
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
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
cfset session.cartTotal = 100
for example, that couldn't cause a problem. Except
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 after its set.
[Todays Threads]
[This Message
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.
The issue
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)
Ray, i believe what
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,
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 is/was some
Subject: RE: Blue Dragon and Fusebox
Here's what I'd like to suggest: we're preparing a public beta of
BlueDragon
3.1 for release in about two weeks; the code is pretty much finished, so
let's get your application running on the latest 3.1 code. Then when 3.1
is
released you can just run
:16 AM
To: CF-Talk
Subject: RE: Blue Dragon and Fusebox
So is the CreateObject() function supported in the new freeversion? I
was very interested in trying BD, but not if you can't run a Fusebox app
on it.
Greg Luce
-Original Message-
From: Vince Bonfanti [mailto:[EMAIL PROTECTED]
Sent
-location
facility she uses.
Assuming most people are honest, I think New Atlanta is spending too
much on marketing.
M
-Original Message-
From: Vince Bonfanti [mailto:[EMAIL PROTECTED]
Sent: Saturday, October 25, 2003 8:27 AM
To: CF-Talk
Subject: RE: Blue Dragon and Fusebox
Here's what I'd
: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 11:44 PM
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
...
Now that issue I have seen before. First, you don't need to use such a
technique with BlueDragon or even CFMX since the application scope is
now automatically
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
-Original Message-
From: Matt Liotta [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 11:44 PM
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
...
Now that issue I have seen before. First, you don't need to
use such a technique with BlueDragon or even CFMX since
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
HTH,
Sam
Haggerty, Mike wrote:
After spending some time on this issue Friday night (and well into
Saturday morning), I convinced my customer to stick with CF5 until BD
3.1 is in full release and we've had a chance to properly test the
application.
What are the reasons that someone would consider
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 still a
best practice
?
-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?
-Original Message-
From: Calvin Ward [mailto:[EMAIL PROTECTED
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?
-Original Message-
From: Calvin Ward [mailto:[EMAIL
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't need to lock in CFMX
you darn well
Here's what I'd like to suggest: we're preparing a public beta of BlueDragon
3.1 for release in about two weeks; the code is pretty much finished, so
let's get your application running on the latest 3.1 code. Then when 3.1 is
released you can just run on that. (There's not much point in debugging
Does anyone know of any limitations using the FB3 core files on the
standard edition of Blue Dragon server? A customer is moving from CF5
to
BlueDragon and reporting the following problem with a Fusebox
application:
I am not aware of any specific limitation, but then again I don't use
FB,
Mike,
that sounds like more of a problem of which version of BD you are using. The
error looked to be due to that version of BD not being able to execute the
createObject()function . I believe with BD3.1 all of that is now
supported. Here's another test you should do : make a similar call in a
]
Sent: Friday, October 24, 2003 3:32 PM
To: CF-Talk
Subject: Re: Blue Dragon and Fusebox
Does anyone know of any limitations using the FB3 core files
on the
standard edition of Blue Dragon server? A customer is moving
from CF5
to
BlueDragon and reporting the following problem
Now, I am assured this is the latest version of BlueDragon, but I have
to ask: was there ever a version that did not support structures?
The latest version of BlueDragon is 3.02, but there is a preview
release of BlueDragon 3.1, which is what most people are testing on
right now. I believe
It looks like you're using the free version of BlueDragon Server (right?),
which doesn't support createObject(). You'll need to use BlueDragon Server
JX ($549/server). We have several clients running applications on FB3 on
both BlueDragon Server JX and BlueDragon/J2EE.
Vince Bonfanti
New Atlanta
Vince -
Thanks for the response.
I think the problem is more complicated than that, createObject() is not
used anywhere in the code.
M
-Original Message-
From: Vince Bonfanti [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 4:41 PM
To: CF-Talk
Subject: RE: Blue
I could be wrong, but it appears BlueDragon does not treat the CF
application scope as a structure, at least not when it is in a CFLOCK.
Is anyone else copying the application scope to a request variable in
BlueDragon?
Now that issue I have seen before. First, you don't need to use such a
49 matches
Mail list logo
