>> It seems like the cursor for a cfoutput gets confused over simultaneous requests, so that a simple cfloop or cfoutput over the query does not work properly.
i'm not surprised, each request is having it's go at the iterator/cursor. either get a reference of the application,query into request scope (and the iterator is request scoped there too or put a cflock around the app.query when each request is wanting to loop over it. IMHO, copying it into a page scope (request/local) is my preference On 3/18/06, Hugo Ahlenius <[EMAIL PROTECTED]> wrote: > Hi, thanks for the response. > > For the testing my little case, it is of course depending on the performance > on the server with my little wait loop there (on BD I used CFPAUSE). > > Your workaround would work, but it would break encapsulation - the object > shouldn't require other pieces of code to use the results any special way... > So I wouldn't recommend it. > > /Hugo > > -----Original Message----- > From: [EMAIL PROTECTED] on behalf of Daniel Roberts > Sent: Fri 2006-03-17 18:04 > To: [email protected] > Cc: > Subject: Re: [CFCDev] application-scoped singletons and thread safety > > > If it is a problem then you could use from/to loops and array > notation (query.field[index]) so you have your own local record index (if > that is in fact the problem) > > > > On 3/17/06, Daniel Roberts <[EMAIL PROTECTED]> wrote: > > here's the code of the page I ran while running your test in > multiple tabs. Run by itself it just outputs 1 but with the other code > running it will randomly flucuated from 1 to 4 > > <cfset thisQuery = APPLICATION.fooObject.getQuery () /> > <ul> > <cfoutput> > <cfloop from="1" to="100" index="i"> > <li>#thisQuery.currentrow#</li> > <cfloop index="counter" from="1" to="100000"> > <cfset temp = counter * rand() /> > </cfloop> > </cfloop> > </cfoutput> > </ul> > > > > > On 3/17/06, Daniel Roberts <[EMAIL PROTECTED]> wrote: > > I tested the file you gave me with around 20 tabs and > saw no problem between each output. I then created another test page to loop > over currentrow 100 times while other tabs were running your code and I can > see that currentrow fluxuates between 1 and 4. > > This is an issue I've never considered. > > > > On 3/17/06, Hugo Ahlenius < [EMAIL PROTECTED] > <mailto:[EMAIL PROTECTED]> > wrote: > > > | What kind of weird things are you seeing? > > It seems like the cursor for a cfoutput gets > confused over simultaneous > requests, so that a simple cfloop or cfoutput > over the query does not > work properly. > > I have an extremely simple/stripped down > testcase here: > http://ftp.grida.no/hugo/testcase.zip > (run this and open some 5-8 windows/tabs in a > browser simultaneously and > compare the results) > > Or you can test the same thing live here: > > http://dev.maps.grida.no/testcase14/testcase.cfm > (look at the lower left bar with the list of > latest graphics, do the > same routine with it) > > Perhaps this test case can be simplified even > more, to just storing the > query in the application scope (and skip the > object). > > It is not so complicated actually, and the > conclusion pretty obvious -- > best practice should be to duplicate() and > not use a reference (for > query variables), since the loop cursor still > sticks with the single > application-wide reference to the variable. > > To reduce coupling, any variables stored in a > singleton local scope > probably should be duplicated anyway - things > calling an object > shouldn't care or know about how things are > cached/stored and they don't > know if things are read-only or not. (and > they shouldn't care if it is a > reference or a duplicated var, at least for > non-object variables) > > > -- > Hugo Ahlenius > > > ------------------------------------------------------------- > Hugo Ahlenius E-Mail: [EMAIL > PROTECTED] > Project Officer Phone: > +46 8 412 1427 > UNEP GRID-Arendal Fax: > +46 8 723 0348 > Stockholm Office Mobile: > +46 733 467111 > WWW: > http://www.grida.no > Skype: > callto:fraxxinus > > ------------------------------------------------------------- > > ########################################### > > This message has been scanned by F-Secure > Anti-Virus for Microsoft Exchange. > For more information, connect to > http://www.f-secure.com/ > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, > send an email to [email protected] with the words 'unsubscribe cfcdev' as > the subject of the email. > > CFCDev is run by CFCZone ( www.cfczone.org > <http://www.cfczone.org> ) and supported by CFXHosting ( www.cfxhosting.com > <http://www.cfxhosting.com> ). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > > > > > > ---------------------------------------------------------- > You are subscribed to cfcdev. To unsubscribe, send an email to > [email protected] with the words 'unsubscribe cfcdev' as the subject of the > email. > > CFCDev is run by CFCZone (www.cfczone.org) and supported by > CFXHosting (www.cfxhosting.com). > > An archive of the CFCDev list is available at > www.mail-archive.com/[email protected] > > > ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
