It may not be correctly worded, but the following has always helped me
understand the extreme views on the topic:
In the world of CF there have two (major) reasons to lock shared scopes.
1) The first reason was simply to protect the Server. In earlier versions
of CF the internal data structures
On Dec 3, 2003, at 6:29 PM, Brian Kotek wrote:
Does NOT need to be locked.
Correct - multiple execution is unimportant.
DOES need to be locked because other threads could be reading from
session.cart.
Only if a single user can initiate multiple requests at the same time
(frames, RIA).
Detai
Thanks Ray...this is helping me get a clearer picture on locking in MX.
Maybe a couple of examples might help me, to be sure. Please let me
know if my assessment is correct or not. Thanks again.
1)
Does NOT need to be locked.
2)
DOES need to be locked because other threads could be rea
On Dec 3, 2003, at 3:34 PM, Brian LeRoux wrote:
Is there a reason to not use cfparam in this case?
I strongly suspect that cfparam is not atomic at the generated code
level and therefore is no more thread safe than the explicit cfif /
cfset approach.
Sean A Corfield -- http://www.corf
Title: RE: [CFCDev] Basic CFC Design Question - Debugging
Yup – in the admin –
turn off the “debugging service”.
Jim Davis
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Middleton
Sent: Wednesday, December 03, 2003
1:14 PM
To: '[EMAIL PROTECTED]'
Subje
> > So if you did:
> >
> >
> >
Is there a reason to not use cfparam in this case?
--
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev'
in the message of the email.
> But Ray, in the example you used, you are clearly NOT sure
> that your variable will only be written to once. Right?
No. Again, it is a waste of time to set application.dsn more than once,
however, it's is a very trivial waste of time.
> So if you did:
>
>
>
>
> Then you would not
But Ray, in the example you used, you are clearly NOT sure that your
variable will only be written to once. Right?
So if you did:
Then you would not need to lock it. But doing it the way you show, with
no check for it's presence before writing to it, you would need to lock
it, and th
You're exactly right. Your example shows the way I prefer, and the way we
went with FB4. I studiously avoided saying CFLOCK, rather just saying
locked, because there are different ways to go about locking stuff. CFLOCK
just happens to be one that CF provides explicitly.
If we take our example a
Basically, it seems to come down to this: if you are storing a value
in
a shared-memory scope, and you are positive that it will only be
written
to once, then you don't need to lock reads or writes to this variable.
If there is any chance that it could be written to more than once, then
you must
> Basically, it seems to come down to this: if you are storing
> a value in a shared-memory scope, and you are positive that
> it will only be written to once, then you don't need to lock
> reads or writes to this variable.
> If there is any chance that it could be written to more than
> once
I would agree...it always seemed to be bashed into everyone's head that
you "always lock everything" in the shared-memory scopes. I think that
I do have some idea of how and why to lock, even in CFMX and even if my
old instinct was to obey the party line and lock everything.
Basically, it seems t
Surely it's a contrived example, but if multiple threads executed it
concurrently, it's entirely possible that 'othervar' and 'thirdvar'
could
contain inappropriate values.
That's is true, but it is also a perfect example of where using a lock
is probably the wrong way to go. Co
I'm not sure if the first one has to be locked. It depends on the Java
bytecode that the CF compiler generates. I suspect it might have to be,
though the window for problems to occur would be really, really small.
However, the latter MIGHT need to be locked. If you set a variables and
then us
My understanding is quite simple - if there is a logical reason to lock,
then you need a lock. What is a logical reason? Here is a simple example:
If 2 (or N) threads run this code at the same time, it is possible the wrong
value would be stored to the variable.
Here is a typical example of som
Not to digress into arguably useless discussions, but the note below
reminded me why I took such offense to people coming up with rules like
"you must always lock shared variable scopes" in the pre-CFMX days. All
those people who memorized that rule are now confused with CFMX because
there is n
We looked at and tested a number of different xml and OODBs.
Utlimately,
nobody felt that any of them were quite up to snuff each for a variety
of
reasons. Do you have any recommendations about XML dbs you've had
good
experiences with (because that's ultimately where we want to go)?
Software
Ray, I must admit that I am one of the people from the "old days" who is
somewhat confused about what/how to lock things in CFMX, especially when
it comes to CFC's persisted in the session or application scope. My gut
instinct is still to lock everything. Without asking you to write a
tome, can y
We looked at and tested a number of different xml and OODBs. Utlimately,
nobody felt that any of them were quite up to snuff each for a variety of
reasons. Do you have any recommendations about XML dbs you've had good
experiences with (because that's ultimately where we want to go)? Right now
w
Unfortunately, all the CFCs get invoked at the request level since each
object is going to be different for each page request. We thought this was
better than dealing with potential locking issues at the app level. Since
the CFCs are so closely tied with the actual HTML generation they really
jus
> The one thing to watch out for is that since the CFC is in a
> shared scope, it's instance data is also in a shared scope,
> and therefore needs to be locked appropriately. There is a
> debate as to whether that's better performed within the CFC
Sorry for the late response on this, but I wa
I'd be a little concerned about how you're caching your database in the
application scope, however. That's just asking for trouble, IMHO. At
the
very least, you should use a revolving cache, so it caches the X most
recently used objects, rather than all of them. You probably want to
look
at th
Invocations are cheap (as long as you turn debugging off). However,
instantiation can be expensive, so as long as you're caching your CFCs in
the application or server scope, you should be fine. Even with simple
Mach-II apps, 50 CFC invocations happens all the time, but for Mach-II,
literally eve
We are in the process of architecting a large CRM system. It's architecture
is heavily CFC based and I am beginning to have some concerns as to whether
what we are doing might be a tad bit crazy in terms of performance under
load. The app stores all aspects of a screen in a database for rendering
Title: RE: [CFCDev] Basic CFC Design Question - Debugging
Sorry to butt in with something unrelated, but I am assuming here you are talking about turning debugging off in the CFAdmin and not playing around in the Service Factory...?
Neil
> With debugging
> on this page was taking upwards of
>
> Well, not quite. The facade is stateless and, as you surmise, is
> instantiated for each Flash Remoting call. It is fairly lightweight so
the
> overhead is minimal. The facade then interacts with CFC instances that
are
> stored in session scope, server scope and/or application scope as
> neces
26 matches
Mail list logo
