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. Ther
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
igured this out by using 'StructCopy' instead of
>'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
[mailto:[EMAIL PROTECTED]
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
It just s
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
It just seems to be a problem with the 'duplicate' function?
~
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
It just seems to be a problem with the 'duplicate' function?
> Okay, we have made some progress on this BlueDr
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
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
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
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 m
: 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
ing values? Or am I just
> misunderstanding your comments.
>
> M
>
> -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
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
sage-
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 the application scope i
run the co-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&
003 8: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 PROTEC
-Talk
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
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
p
> 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 su
Dragon and Fusebox
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 BlueDrag
nti
New Atlanta Communications, LLC
http://www.newatlanta.com
-Original Message-
From: Haggerty, Mike [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2003 3:22 PM
To: CF-Talk
Subject: Blue Dragon and Fusebox
Does anyone know of any limitations using the FB3 core files on the
standard
> 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
PROTECTED]
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 fo
et us know
- Original Message -
From: "Haggerty, Mike" <[EMAIL PROTECTED]>
To: "CF-Talk" <[EMAIL PROTECTED]>
Sent: Friday, October 24, 2003 3:22 PM
Subject: Blue Dragon and Fusebox
> Does anyone know of any limitations using the FB3 core files on th
> 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
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:
BlueDragon Runtime Error
Request /index.cfm
File Trace C:/Program Files/New
Atla
50 matches
Mail list logo
