I'm not sure why but this didn't post...

-----Original Message-----
From: Christine Lawson 
Sent: Friday, May 03, 2002 12:25 PM
To: '[EMAIL PROTECTED]'
Subject: RE: CF5 & MX Locking <cflock>


Hi Dennis,
You still need to lock in CF 5 and as a best practice you should in MX. The difference 
between MX and 5 is that in MX the Java data structures used as scopes are designed to 
be thread-safe. For a better understanding of why you need to lock in version 5 and 
earlier I suggest you read Jim Schley's locking article 
(http://www.macromedia.com/v1/handlers/index.cfm?id=17318&method=full). 

There was also a discussion about this yesterday too, if you go to this page: 
http://www.mail-archive.com/cf-talk@houseoffusion.com/thrd2.html scroll down to the CF 
Wishlist discussion, various posts are about locking in CFMX.

Hope that helps,
Christine 

-----Original Message-----
From: UXB Internet [mailto:[EMAIL PROTECTED]]
Sent: Friday, May 03, 2002 10:28 AM
To: CF-Talk
Subject: CF5 & MX Locking <cflock>


Hello,

At the risk of being charged with equine abuse, I just want to be sure that
I understand the locking issue. Especially since every time I think I
understand some one says something to change my worldview.

We are still using CF 4.0.1 so I assume that locking to prevent memory
corruption is required.

In the attached message, Mr. Camden implies that at some version level, and
I assume it is CF5 and CFMX, locking session, application and server
variables to prevent memory corruption is _not_ required.  However running
code within an application in two browser windows, simultaneously, using the
same session (same CFID/CFTOKEN) can cause unpredictable results when
manipulating "memory variables" in the session and application scope.

To further illustrate what I think he was inferring, assume that I had a
page that took an input, did a query, and then added the query count to a
session variable.  I open two browser windows and supply different inputs to
the same template in each window.

Window 1:
Session.x = 1
Input = a
Query time = 5ms returns a value=5
Session.x=session.x + querycount

Run separately he session.x value should be 6

Window 2:
Session.x = 1
Input = e
Query time = 15ms returns avalue=5000
Session.x=session.x + querycount

Run separately the session.x value should be 5001

However if I run the template in the two browser windows simultaneously,
where cfid/cftoken is the same, I _could_ get a result of session.x = 5006
in window 2 since window 1 finished first.  Is this correct?

It appears as if I have never _really_ understood the reasons behind the
locking issue and only just the safety guidelines, so any and all help is
greatly appreciated.

Best regards,

Dennis Powers
UXB Internet - A Web Design and Hosting Company
tel: (203)879-2844  fax: (203)879-6254
http://www.uxbinternet.com/
http://dennis.uxb.net/


-----Original Message-----
From: UXB Internet [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 6:17 PM
To: CF-Talk
Subject: RE: CF Wishlist


-----Original Message-----
From: Raymond Camden [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, May 01, 2002 4:38 PM
To: CF-Talk
Subject: RE: CF Wishlist

cflock is _not_ necessary for memory issues anymore. You still need it
for logical reasons. For example:

application.x = application.x + 1

Without locks, it's possible two threads could run the same code at
once. Instead of x being x+2, it would be x+1.

=======================================================================
Raymond Camden, Principal Spectra Compliance Engineer for Macromedia

Email    : [EMAIL PROTECTED]
Yahoo IM : morpheus

"My ally is the Force, and a powerful ally it is." - Yoda

> -----Original Message-----
> From: UXB Internet [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, May 01, 2002 4:25 PM
> To: CF-Talk
> Subject: RE: CF Wishlist
>
>
> To stay on topic, and most likely cause more trouble, I on
> the other hand
> would like <cflock> to go away and not be necessary for
> session, application
> or server variables.  It is my firm belief that variable
> locking should be
> part of the core CF engine and not part of the higher level scripting
> language.  Especially since it appears to always be required.
>  As much as I
> understand the reasons for it's current existence in a multi-threaded
> environment, <cflock> still has the appearance of being a
> patch to a design
> flaw.
>
> Best regards,
>
> Dennis Powers
> UXB Internet - A Web Design and Hosting Company
> tel: (203)879-2844  fax: (203)879-6254
> http://www.uxbinternet.com/
> http://dennis.uxb.net/
>
>
> -----Original Message-----
> From: David Schmidt [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, April 30, 2002 12:42 PM
> To: CF-Talk
> Subject: CF Wishlist
>
> Ok,
>
> Have carefully considered what I want from CF, the most
> striking feature I
> want to see is...
>
> "Stop treating empty list items as null."  That is a list of
> "3,5,,,3,2,2"
> should have a length of 7, instead of 5.  Doing this would
> nearly eliminate
> the need for any field names like name="cost_#i#", since HTML
> sends back
> "3,5,,,3,2,2" for duplicate text fields named "cost" anyways.
>
>
>
>



______________________________________________________________________
Structure your ColdFusion code with Fusebox. Get the official book at 
http://www.fusionauthority.com/bkinfo.cfm
FAQ: http://www.thenetprofits.co.uk/coldfusion/faq
Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists

Reply via email to