Greetings all-
I realize this topic may have been covered on this list a while back, but
I'm having problems locating a good answer, so here goes. Typically in our
administrative web sites, on a request, we copy over our session variables
to the request scope so we can have read-access to the
As you know, cfset session.object = request.object / only
creates a pointer to original, and duplicate() doesn't work on CFCs
(we're using CFMX 7). Anyone have a workaround or best-practice solution
for this type of thing?
No workaround is needed. You don't need anything more than a
I realize this topic may have been covered on this list a while back, but
I'm having problems locating a good answer, so here goes. Typically in our
administrative web sites, on a request, we copy over our session variables
to the request scope so we can have read-access to the information
Anyone have a workaround or best-practice solution for this type of
thing?
The easiest would be that one no longer needs to have locks everywhere when
reading session or other global scopes. The bugs that where the reason for
this old rule of thumb have long been handled. This has not been a
How about a method in all your CFCs called 'copy' (perhaps in a generic base
cfc that they all inherit from):
cffunction name=copy access=public
cfreturn this
/cffunction
I'm quite sure that doesn't return a pointer (no time to test the theory but
I'm sure someone could verify that).
Regards,
I'm quite sure that doesn't return a pointer (no time to test the theory
but I'm sure someone could verify that).
No, it returns a reference, just like any other assignment that doesn't
explicitly use Duplicate.
Dave Watts, CTO, Fig Leaf Software
I'm not clear on why you would want to copy the instance instead of create a
reference to it.
That said, you could serialize the original and then deserialize the
serialized version to make a true clone of the object (this requires using
Java though). You could even wrap up this logic into a
Subject: RE: Copying a CFC Persisted in Session Scope
I realize this topic may have been covered on this list a
while back,
but I'm having problems locating a good answer, so here goes.
Typically in our administrative web sites, on a request, we
copy over
our session variables
,AuthenticatedUser).copy(
session.myAuthenticatedUs
er) /
/cflock
Thanks!
Ryan
-Original Message-
From: Rich [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 12:40 PM
To: CF-Talk
Subject: RE: Copying a CFC Persisted in Session Scope
I realize this topic may have been
, and to be honest,
I haven't found a lot of information either way on the issue, so copying the
object seems to be playing it safe, no?
-Original Message-
From: Brian Kotek [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 3:43 PM
To: CF-Talk
Subject: Re: Copying a CFC Persisted in Session
On 10/29/07, Rich [EMAIL PROTECTED] wrote:
I would suggest that you create a Session Facade and then have all your
objects reference the façade. It is generally a bad idea to have an object
reference an external scope (session, request, etc.), and this technique
hides the implementation from
: Monday, October 29, 2007 4:00 PM
To: CF-Talk
Subject: Re: Copying a CFC Persisted in Session Scope
On 10/29/07, Rich [EMAIL PROTECTED] wrote:
I would suggest that you create a Session Facade and then have all
your objects reference the façade. It is generally a bad
idea to have
an object
, no?
-Original Message-
From: Brian Kotek [mailto:[EMAIL PROTECTED]
Sent: Monday, October 29, 2007 3:43 PM
To: CF-Talk
Subject: Re: Copying a CFC Persisted in Session Scope
Yes, but why are you creating a copy in the first place? Why
do you think you need a copy and not a reference?
On 10
Yes, but why are you creating a copy in the first place? Why do you think
you need a copy and not a reference?
I think he is copying from the session scope to the request scope, and he
does not want to change the session object's values when changing with the
request object's values.
-- Josh
There should, since MX6 or so, be no reason to create read-only locks
unless you have some sort of weird race condition going on. All session
vars are thread-safe, and so cannot be simultaneously read and written to.
So, you don't need to be absolved from locking even if you are
referencing
Ryan Heldt wrote:
The objects I am copying from are persisted in the session scope. I would
like to be able to read from these objects at runtime without having to lock
them all over the place. Does creating a pointer in the request scope to an
object in session absolve you from locking? I'm
Unless you have an issue with race conditions, you don't have to bother with
any of this. If you do have a situation where a race condition will cause an
error, just add locking for that situation.
On 10/29/07, Ryan Heldt [EMAIL PROTECTED] wrote:
The objects I am copying from are persisted in
And having references to sessionFacade.getFoo() everywhere is somehow
better than having references to session.foo?
I think you are getting stuck on the name 'sessionFacade'; I was attempting
to suggest abstracting access to the variable of which his components had no
direct knowledge. If my
At the risk of disagreeing with Sean, which usually ends up with me
realizing I'm wrong about something...
On 10/29/07, Sean Corfield [EMAIL PROTECTED] wrote:
And having references to sessionFacade.getFoo() everywhere is somehow
better than having references to session.foo?
I do see a
The objects I am copying from are persisted in the session
scope. I would like to be able to read from these objects at
runtime without having to lock them all over the place. Does
creating a pointer in the request scope to an object in
session absolve you from locking? I'm not sure, and
That is, in fact, what I am doing. I have a AuthenticatedUser
CFC that contains all of the information about the user that
is signed in. Now, for example, say I want to run a query
that gets all of the timebills for that user, I would SELECT
foo FROM bar WHERE UserID =
On 10/29/07, Rich [EMAIL PROTECTED] wrote:
I think you are getting stuck on the name 'sessionFacade';
Only because that's what most people do *literally*.
I was attempting
to suggest abstracting access to the variable of which his components had no
direct knowledge. If my code is calling
On 10/29/07, Brian Kotek [EMAIL PROTECTED] wrote:
And since I have never run into a situation where different
services needed to use different persistence mechanisms
I have. One day you will too.
peeveAnd it's not persistence - memory is not persistent by
definition, disk-based systems are
On 10/29/07, Brian Kotek [EMAIL PROTECTED] wrote:
just because I do this, I was missing the fact that many people might not
impose the same limitation on themselves. By eliminating the centralized
facade, you're not even giving other services the possibility of digging
into shared scope data
On 10/29/07, Sean Corfield [EMAIL PROTECTED] wrote:
For mock testing, just extend that service CFC and override that one
method. That one method is often responsible for creating the cached
object on-demand so the extended mock can double up as both a mock for
the cache access and a way to
I'm curious, then, how you handle reference to the session scope in your
service. Do you actually reference the session scope directly? One of the
things I like about the centralized SessionFacade is that it is easy to test
by feeding in a fake struct that the facade uses in place of a real
On Oct 30, 2007 12:46 AM, Sean Corfield [EMAIL PROTECTED] wrote:
Once a
service has access to a generic facade like that, it can access *any*
data behind that facade and the faux-encapsulation of the facade
encourages developers to do so, believing they're using good OO
practice. All that
27 matches
Mail list logo
