> Builtin variable locking at the object level doesn't lock the entire
> SCOPE="SESSION", it only locks the paricular variable that
> you are accessing (as in ASP). This is one of the major pains of
> CFLOCK, that I must lock the entire application scope just to
> retrieve an object reference from
> locking on a per-object basis. I'll give you an example. Let's say you're
> retrieving two variables from shared memory:
>
>
>
>
> If the variables themselves handled their own locking (if, for instance,
you
> instruct the CF server to lock reads automatically in the CF
Administrator),
> you'd
> It is quite plain that simple variables are not thread-safe
> in CF. Does anyone know whether CF structures are thread-safe
> or not? The MFC have thread-safe collection classes, but I
> don't know if Allaire 'rolled their own' for Cold Fusion.
As far as I can tell, any native CF data object (s
If no one else knows these answers, you should take this up with Simeon,
he's the man with the answers.
Steve
-Original Message-
From: Benjamin Smedberg [mailto:[EMAIL PROTECTED]]
Sent: Monday, April 10, 2000 1:25 AM
To: [EMAIL PROTECTED]
Subject: Re: CFLOCK revisited, part 2
> It goes on to give an example where they CFSET a local variable to an
> application variable. I don't know whether they are passing by reference
or
> not, but leads me to think that locking aliased local variables that refer
> to Application or Session scoped variables is a good idea.
I am us
Sunday, April 09, 2000 6:03 PM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: CFLOCK revisited, part 2
> This is what I do. Since most of my cached data is either strings
> or structures I use one of two methods to create "local" copies.
>
> 1) If the cached data is a s
> This is what I do. Since most of my cached data is either strings
> or structures I use one of two methods to create "local" copies.
>
> 1) If the cached data is a string, I create a local copy by
> using (in a CFLOCK of course):
>
>
> Since CF passes by reference if you leave out the concaten
Dave,
Thank you for your comments to both of my threads.
>Given that Allaire recommends the use of the SCOPE attribute to lock memory
>variables instead of the NAME attribute, there is probably some reason
you'd
>want to lock access to the entire scope.
I didn't consider that point. I use CF 4
> From what I've read so far, the standard lock name relates
> to the scope being accessed. For example, accesses to the
> application scope use a lock name of #Application.ApplicationName#
> and accesses to the session scope use a lock name that is unique
> to that user session, such as the conca
Another question on CFLOCK:
>From what I've read so far, the standard lock name relates to the scope
being accessed. For example, accesses to the application scope use a lock
name of #Application.ApplicationName# and accesses to the session scope use
a lock name that is unique to that user sessi
10 matches
Mail list logo
