Actually that reminded me of why I brought up myspace in the first place.
I have noticed the page views jump up and down on a regular basis, because
someone else has hit the page and when my session has finished it says lets
say 166, then when they finish and I go to view it again it has gone back to
160.
You can't tell me that this occured due to anything else than a race
condition.
On 4/15/07, Andrew Scott <[EMAIL PROTECTED]> wrote:
>
>
> Ok as Sean said, on its own that doesn cause a race condition. So no thats
> true.
>
> But, lets say somewhere else in the code you require that same variable
> for other reporting. And in the meantime of you begining to do the
> reporting, that variable changes. Hence a race conditon has occured.
>
> The argument is not about one variable on its own, as stated the orignal
> Author has a CFC stored inside a session variable, this is a classic exmple
> that data is changing when he is reading the data out of the CFC, so when
> this occurs it is a race condition that is happening.
>
> Forget the one line hit count, as stated on its own and even Ben said that
> but if you are worried about a race condition lock it and thats what is
> happening here.
>
> I am not interested in anyone saying that one set is going to cause a race
> condition, I am more interested in the problem put forward and I am sorry to
> say that cflock is required under these circumstances.
>
> If anyone else wants to debate the ins and outs of race conditions then
> take it offline, if however you want to discuss the problem this user is
> having then so pist away, but I will stand by the statement I made this is a
> race condition scenario and it should be treated as such and locked.
>
>
> On 4/15/07, Jochem van Dieten <[EMAIL PROTECTED]> wrote:
> >
> > Andrew Scott wrote:
> > >
> > > Thats what I mean, best practice says use cfqueryparam, and every
> > document
> > > you read regardless of cfmx 5.0, 6.0, 7.0 says when writing to a
> > variable
> > > you will have a race condition.
> >
> > Just because you can have a race condition doesn't mean you will have a
> > race condition.
> >
> >
> > > Now I can't name the version I tested this on, but I followed one of
> > the
> > > articles directions on how a race condition will work. And you know
> > what, it
> > > proves that even this version of Coldfusion needs cflock around
> > perstant
> > > variable writes.
> >
> > No it doesn't. It proves that CF needs locking to prevent race
> > conditions with some code constructs. It does not prove that CF needs
> > locking with all writes to shared variables.
> >
> >
> > Let me give you the simplest possible example. Let's suppose I have the
> > following code in my onRequestStart to get a timestamp with a timezone
> > compensation:
> > <cfset session.lastHit = DateAdd('h', -1, Now())>
> >
> > I can use this variable to display the following to the user:
> > <cfoutput>
> > Last session activity as #session.lastHit#
> > </cfoutput>
> > This works lock-free without any problems.
> >
> > I can also use this variable to display the following to the user:
> > <cfoutput>
> > Page requested at #session.lastHit#, generated in #timer# ms.
> > </cfoutput>
> > This will show incorrect information in case of overlapping requests.
> >
> >
> > Race conditions depend just as much on the meaning you give to a
> > variable when reading it, as on the timing of the writing.
> >
> > Jochem
> >
> >
> >
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~|
Create robust enterprise, web RIAs.
Upgrade & integrate Adobe Coldfusion MX7 with Flex 2
http://www.adobe.com/products/coldfusion/flex2/?sdid=RVJP
Archive:
http://www.houseoffusion.com/groups/CF-Talk/message.cfm/messageid:275262
Subscription: http://www.houseoffusion.com/groups/CF-Talk/subscribe.cfm
Unsubscribe: http://www.houseoffusion.com/cf_lists/unsubscribe.cfm?user=89.70.4
