Is the constructor in a CFC always called in CFMX when you call a method
in that CFC? That's seems a bit odd to me.
In my imagination, I only call the init method once, when I create the
object in the application scope. After that the init is not directly
invoked by me.
The second example
Nevermind, I see what you mean, it was a bug in the second part. That
line should only call init on the IOFactory in the variables scope.
Micha Schopman
Software Engineer
Modern Media, Databankweg 12 M, 3821 ALAmersfoort
Tel 033-4535377, Fax 033-4535388
KvK Amersfoort 39081679, Rabo
A few things.
1) The lock isn't really necessary if you don't have any race conditions.
2) Why do you create a copy of application.IOFactory in the variables
scope? You don't need to normally. I'd just have code like so:
cfif not isDefined(application.foo)
cfset application.foo =
The lock I placed here was more like a simulation of what I wanted to
do, code within could crash on race conditions (although that should be
impossible with a correct CFC).
The reason why I copy the application,scopeinto a variables scope, is
to use the CFC throughout the application without
| To: CF-Talk
| Subject: RE: Caching CFC's
|
| The lock I placed here was more like a simulation of what I
| wanted to do, code within could crash on race conditions
| (although that should be impossible with a correct CFC).
|
| The reason why I copy the application,scopeinto a variables
| scope
So I merely created a pointer ... ... erm .. oops? ..
It is kunda frustrating working with CF since the betas but never being
able to work with CFMX because management denied it based on the
risc. now is the time to strike back ;) My hope is on a quite big
improvement in processing
, 2004 14:16
| To: CF-Talk
| Subject: RE: Caching CFC's
|
| The lock I placed here was more like a simulation of what I
| wanted to do, code within could crash on race conditions
| (although that should be impossible with a correct CFC).
|
| The reason why I copy the application,scopeinto
One other thing about storing the cfc in the application scope was
that any changes to the CFC wouldn't be reflected until the
application re-started. So I'd also consider adding something like
this:
cfif NOT IsDefined('application.IOFactory') OR
(isDefined(url.killApp) AND url.killApp eq yes)
Always.. there are more caching system involved in the application, but
since it is production the only time you have to flush them is when you
change framework files.
Micha Schopman
Software Engineer
Modern Media, Databankweg 12 M, 3821 ALAmersfoort
Tel 033-4535377, Fax 033-4535388
KvK
I tested a combination, one object created in the application scope, and
one in the variables scope:
In both outputs, I get the exact same time. In the application scope I
thought it would be set in the CFC, so next time I would call the CFC I
would get the old time back. The second CFC should
On every request you are rerunning init on the application.IOFactory
object. Therefore it makes sense that your time values match. Remove
that line and it should work fine.
On Thu, 22 Jul 2004 16:01:14 +0200, Micha Schopman
[EMAIL PROTECTED] wrote:
I tested a combination, one object created in
Does someone now ways to do some CFC caching?
Storing CFCs, including instance data, in the Session scope certainly seems
to work for me - I imagine Application would be the same.
I do it very simply like this:
cfif not isDefined(Session.cfcInstanceName)
cfobject component=cfcName
On Thu, 22 Jul 2004 14:16:20 +0200, Micha Schopman
[EMAIL PROTECTED] wrote:
The reason why I copy the application,scopeinto a variables scope, is
to use the CFC throughout the application without the need to relock
again with a type=read to access the methods
In my opinion, the only sorts of
13 matches
Mail list logo
