Michael S Hodgdon
Web Development Project Manager
617 - 669 - 7183
[EMAIL PROTECTED]
----- Original Message -----
From: Raymond Camden
To: CF-Talk
Sent: Wednesday, February 25, 2004 10:46 AM
Subject: RE: problems accessing variables with components
> Please see my comments in the code below.
Ditto.
[deleted stuff]
> issues under load.
>
> {Michae Hodgdon} - These values are indeed persistant.
> This information rarely changes, so rather than make constant
> database hits, we are keeping the aMarkets array in a
> structure called sthcpInfo. stHcpinfo also holds other
> persistant information that we would like to keep
> persistance. So essentially, this information is designed to
> be read only, and set in memory only on initialization of
> this object. Access is received through the getRoutines that
> we have set.
Ok - you still need to var scope any other variable, like current_market.
> > <!--- For each market returned by the database... --->
> > <cfloop from="1" to="#ArrayLen(sthcpInfo.aMarkets)#"
> > step="1" index="current_market">
>
> > <cflock scope="SERVER" type="EXCLUSIVE" timeout="30">
> >
> > <!--- Create a new topic object for this market in server
> > memory--->
> > <cfset
> > "server.#sthcpInfo.aMarkets[current_market].topic#" =
> > CreateObject("component", "cf_components.topic")>
>
> Why do you do this? You are already storing the CFC itself
> in server memory
> - why not store these values in the CFC itself - in the
> Variables scope.
> Then the values will exist as long as the CFC itself exists.
> {Michael Hodgdon} - Each market has many routines that it
> runs as well personal information about that market. So we
> are using the "topic" cfc as a blueprint, and then we create
> an object for each market using that blueprint. For easy
> access, we reference the aMarkets cfc to output all the
> markets we have (for instance, on the home page our markets
> are ....). When you are on a market page itself, we access
> that markets objects to return more detailed and rich information.
Ok - but this still doesn't change my question. You have N CFCs, one for
each market. Why not just store it in the main CFC itself? Referencing the
server scope like this is - normally (and again, in my opinion) a bad idea.
>
> <cfset
>
> server[sthcpinfo.amarkets[current_market]].topic.initializeObj
> ect(....)>
>
> Again though, I'd move this stuff out of the server scope anyway.
>
> {Michael Hodgdon} - interestingly so, that is something we
> have been questioning ourselves. Our initial intent was to
> minimize server load by keeping persisant read only memory on
> hand in the server scope.
Which is a good idea.
> For instance, aMarkets rarely
> changes. In fact most of whats in the hcp.cfc rarely
> changes. Therefore, rather than constantly load these
> objects into local memory, we drop them into the server scope
Right - I'm not saying to NOT use the server scope, but to simply use a
simpler model. If the A.cfc has N instances of B.cfc, you can simply have
A.cfc keep these guys inside itself. Then when A.cfc is persisted, its local
B CFCs are persisted as well.
> and access them there. Are you saying that because these
> objects are stored in server memory and all of our web users
> access that same object in server memory we could be creating
> problems? We are really concerned about server load and
> performance. If we are loading these objects into local
> memory rather than server, should we not be concerned with this?
No, because the CFC that holds them itself is being persisted.
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings]
