do, code within could crash on race conditions (although that should be
impossible with a correct CFC).
The reason why I copy the application,scope into 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 case of race
conditions). I also could just call the application scope, without
locking, but It has become common since I still work a lot with CF5, and
less with CFMX due to company management decisions. But you're right in
terms of, when race conditions do not affect the cfc, the locking is
unneeded. (also because cfmx has fixed locking memory leaks).
I thought about this technique because I use a framework which is very
much build upon a single file which checks for locations of files,
inheritance, overriding for customers, etc. and this file is called
about 6 times per request. So I thought, why recall that file (*.cfc)
again and again while the contents are exactly the same. Every customer
uses a specific directory to read files from, but these files get
overrided when the customer has a file with the exact name in its own
directory. This structure is cached in a struct, and it would be great
if I can create some sort of persistency for the duration of the
application scope, without calling the CFC on each request, but instead
calling the code in memory for each request.
It was merely a thought about in memory processing of code, which
ofcourse is the fastest way of processing code, but I do not have a clue
if this could lead to unwanted errors :-)
Micha Schopman
Software Engineer
Modern Media, Databankweg 12 M, 3821 AL Amersfoort
Tel 033-4535377, Fax 033-4535388
KvK Amersfoort 39081679, Rabo 39.48.05.380
[Todays Threads] [This Message] [Subscription] [Fast Unsubscribe] [User Settings] [Donations and Support]
