Jason,

If that query is stored in the service object variables/this scope and
the service is stored in the app scope, then yes - you should use
duplicate() like you are outlining.

/H.


--
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
------------------------------------------------------------- 








 

| -----Original Message-----
| From: [EMAIL PROTECTED]
| [mailto:[EMAIL PROTECTED] On Behalf Of Jason Daiger
| Sent: Tuesday, March 21, 2006 18:28
| To: [email protected]
| Subject: Re: [CFCDev] application-scoped singletons and thread safety
| 
| I've been following this thread w/ great interest and have a final 
| question but first let me set the scenario.  I have a service that 
| stores a lookup collection.  The service and all its member variables 
| are stored in application scope.  The lookup collection (one of the 
| member variables stored by the
| service) returns a query to the caller.  
| The caller then does whatever it wants (looping most likely) w/ the 
| query it has received.  So based on what I'm reading I should have the

| service use duplicate before returning the query.  Something like this

| <cffunction name="getLookup"
| returntype="query">
|     <cfargument name="lookupCode" type="string">
| 
|     <!--- The following uses the lookupsAggregator object to find the 
| lookup and return all the lookup values for that lookup code.  If 
| nothing is found it returns an empty query --->
|     <cfset var retVal =
| _me.lookupsAggregator.getLookupValues(arguments.lookupCode)>
|     <cfreturn duplicate(retVal)
| </cffunction>
| 
| Have I read and understood this thread correctly?
| 
| -Jason
| 
| 
| 
| Hugo Ahlenius wrote:
| > Barry,
| >
| > I don't think it is not that simple/obvious -- you store a
| query for
| > caching and ONLY reading, then it is not obvious that the 
| > currentrow/loop cursor is written - I actually took for
| granted that
| > the cursor would be per request, and was not an integral
| part of the
| > actual variable/query.
| >
| > I would strongly recommend against cflock here, use duplicate.
| >
| > /H.
| >
| >
| > --
| > 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
| > -------------------------------------------------------------
| >
| >
| >
| >
| >
| >
| >
| >
| >  
| >
| > | -----Original Message-----
| > | From: [EMAIL PROTECTED]
| > | [mailto:[EMAIL PROTECTED] On Behalf Of Barry Beattie
| > | Sent: Tuesday, March 21, 2006 12:11
| > | To: [email protected]
| > | Subject: Re: [CFCDev] application-scoped singletons and thread 
| > | safety
| > | 
| > | the biggest issue is usually understanding what's happening.
| > | 
| > | just because there's a couple of lines of code together
| with a loop
| > | only means those instructions are being executed sequentually 
| > | _by_that_thread. In between which, other threads have
| their "slice
| > | of the processor" to run instructions and, in this case,
| access to
| > | common
| >
| > | memory (ie:  Application scoped variables).
| > | 
| > | All shared scopes have this issue to consider and that's
| why cflock
| > | (yeah it *is* an ugly way to go) works: deny other
| threads access to
| > | this shared scope until the first thread hits the
| </cflock>. copying
| > | the data and using the copy for processing avoids the issue.
| > | 
| > | it's also related to the old
| > | 
| > | if app var doesn't exist
| > |   lock
| > |   if it still really doesn't exist (not created by another thread 
| > | while locking this thread)
| > |     create app var
| > |   end if
| > |  end lock
| > | end if
| > | 
| > | 
| > | it's an easy thing to forget when you're deep in the
| innards of some
| > | code.
| > | 
| > | my 2c
| > | barry.b
| > | 
| > | 
| > | 
| > | On 3/21/06, Hugo Ahlenius <[EMAIL PROTECTED]> wrote:
| > | > I experimented a bit more, and it has nothing to do with
| > | CFCs really
| > | > -- in  the application scope (and also likely in other
| > | shared scopes)
| > | > the currentrow cursor is shared with the queries, at least
| > | in CFMX 6.1
| > | > and BD 6.2.1 (which I have tested, don't have access to CFMX 7).
| > | >
| > | > Workarounds:
| > | > * Best is to duplicate (for encapsulation etc)
| > | > * One can also cflock (ugly!)
| > | > * Or do an index loop 1 to recordcount
| > | >
| > | >
| > | > --
| > | > 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) 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]
| > | 
| > | 
| > | 
| > | 
| > | 
| > ###########################################
| >
| > 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) and supported by
| CFXHosting (www.cfxhosting.com).
| >
| > An archive of the CFCDev list is available at 
| > www.mail-archive.com/[email protected]
| >
| >
| >
| >   
| 
| --
| Jason Daiger
| URL: www.jdaiger.com
| EML: [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]
| 
| 
| 
| 
###########################################

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) and supported by CFXHosting 
(www.cfxhosting.com).

An archive of the CFCDev list is available at 
www.mail-archive.com/[email protected]


Reply via email to