throw an error, but it doesn't copy it correctly. Ditto for CFWDDX.
You can serialize a CFC but your packet can't be deserialized
correctly.
-Ray
On Thu, 22 Jul 2004 14:50:58 +0200, Hugo Ahlenius
<[EMAIL PROTECTED]> wrote:
> Micha,
>
> If I remember the code you sent correctly -- you didn't copy anything
> anywhere, remember that CFCs/structs and others are only copied by
> reference, you need Duplicate() to do that. I think you lose some of the
> point with the caching, as well, by copying the whole cfc.
>
> What you should do -- make sure that the component doesn't store any
> instance data after init(), and if they do, then it should be locked.
> And make sure the component is thread safe.
>
> --
> Hugo Ahlenius
>
> -------------------------------------------------------------
> Hugo Ahlenius E-Mail: [EMAIL PROTECTED]
> Project Officer Phone: +46 8 230460
> UNEP GRID-Arendal Fax: +46 8 230441
> Stockholm Office Mobile: +46 733 467111
> WWW: http://www.grida.no
> -------------------------------------------------------------
>
> | -----Original Message-----
> | From: Micha Schopman [mailto:[EMAIL PROTECTED]
> | Sent: Thursday, July 22, 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,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]
