Hmmm ... I don't know ...
Hugo, I'm wondering about the method you employed
to "load test" your code, and the conclusion you came to. Running it in
multiple browser
tabs - observing something, and then concluding
that you should
duplicate all application scoped variables when reading them and
looping over seems a little dicey to me. Is that the way a Java
engineer would load test the multi-threaded capabilities of the CFMX
codebase? I have no idea, but i certainly hope they've got a more
sophisticated approach.
I've used queries cached in application scoped singletons in many
instances of an application that have been in production for a long
time now and never observed a problem with it. That doesn't prove or
disprove anything. But Hugo, if your assumption is correct, then it
would seem there's a fundamental flaw in the way CFAS handles shared
scoped variables, and if this is the case, i'm wondering why this
hasn't been noticed before.
Who knows tho' - perhaps you're the first to notice it.
Nando
Jason Daiger wrote:
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]
----------------------------------------------------------
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]
|
