://www.uxbinfo.com/
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 7:14 PM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Yes, you need to place a lock around any reads or writes of Session
variables. If you don't lock reads as well
PROTECTED]]
Sent: Thursday, August 09, 2001 9:07 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Maybe I am being a curmudgeon today, but it seems to me that if you ALWAYS
need to lock session and application variables and would never want to use
them without locks then Allaire
Maybe I am being a curmudgeon today, but it seems to me that if you
ALWAYS need to lock session and application variables and would never
want to use them without locks then Allaire should have coded that
function into it's core design.
Maybe so. I can't speak to that, since I don't know
): MediaEmbee
MSN: [EMAIL PROTECTED]
Yahoo: MediaEmbeeYH
-Original Message-
From: Dennis Powers [mailto:[EMAIL PROTECTED]]
Sent: Thursday, August 09, 2001 7:07 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Maybe I am being a curmudgeon today, but it seems to me
: Thursday, August 09, 2001 9:24 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
had they done that,
it likely would have placed a lock around each individual use.
which would have been hard on performance.
as they left it,
you control what to lock, which allows you to place a single
://www.uxbinfo.com/
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Monday, August 06, 2001 7:14 PM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Yes, you need to place a lock around any reads or writes of Session
variables. If you don't lock reads as well
:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 10:01 AM
Subject: RE: I don't understand session locking :(
Wouldn't you actually need to use the Duplicate() function here when
referencing the session variable? I seem to recall past discussions that the
process of making a copy in this way
We're right in the throes of this, too. We've been operating under
the understanding that using Duplicate() was necessary ONLY when dealing
with complex variables.
Thus, cfset request.variablename = session.variablename
would work fine as long as session.variablename is not complex.
: Chris Norloff [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, August 08, 2001 12:42 PM
To: CF-Talk
Subject: cfset and/or Duplicate() [was:RE: I don't understand session
locking :(
We're right in the throes of this, too. We've been operating under the
understanding that using Duplicate() was necessary
Subject: RE: I don't understand session locking :(
Question here as well
I have done locks when ever I set a Session var.
Do I have to use a lock when ever I use the var?
i.e:
CFLOCK type=readonly scope=session
CFSET session.bgcolor = blue
/CFLOCK
body bgcolor
Wouldn't you actually need to use the Duplicate() function here when
referencing the session variable? I seem to recall past discussions that the
process of making a copy in this way actually only created a pointer to the
session variable and left you vulnerable to the locking issue. Using
Yes
-Original Message-
From: Ken Wilson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 10:01 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Wouldn't you actually need to use the Duplicate() function here when
referencing the session variable? I seem
Changing from session to client
Are there any limitations on client vars, other than db size?
Could structures and arrays be a problem?
Looking at the table, cdata, the client vars are all dumped into one field,
can this be changed?
and is there a way to automatically delete them when a user
:[EMAIL PROTECTED]]
wrote:
Yes
-Original Message-
From: Ken Wilson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 10:01 AM
Subject: RE: I don't understand session locking :(
Wouldn't you actually need to use the Duplicate() function here when
referencing the session variable
Wouldn't you actually need to use the Duplicate() function here
when referencing the session variable? I seem to recall past
discussions that the process of making a copy in this way actually
only created a pointer to the session variable and left you
vulnerable to the locking issue.
Aren't all session vars stored as structures, regardless of their actual contents?
Wouldn't this necessitate duplicate() everywhere regardless of var contents?
--Matt--
-- Original Message --
from: David Shadovitz [EMAIL PROTECTED]
Reply-To: [EMAIL
Changing from session to client
Are there any limitations on client vars, other than db size?
Could structures and arrays be a problem?
Yes. If you want to store structures, arrays or queries in the Client scope,
you'll have to convert them to strings; you can easily do this with WDDX.
Aren't all session vars stored as structures, regardless of
their actual contents? Wouldn't this necessitate duplicate()
everywhere regardless of var contents?
If you want to pass the session variable itself (with its contents) by
value, you'd need to use Duplicate. If you want to pass a
Correct. Thanks for the clarification. :)
-Tyson
-Original Message-
From: Ken Wilson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 10:01 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Wouldn't you actually need to use the Duplicate() function here
dealing with complex nested data structures in WDDX,
it's very easy to bump over 4kb in size with a WDDX packet.
-Tyson
-Original Message-
From: Dave Watts [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 1:31 PM
To: CF-Talk
Subject: RE: I don't understand session locking
Thx Dave. Looks like your original answer and my question came in right at about the
same time.
Nice to have this finally clarified. Have been using duplicate to be on the safe side.
Is there a performance penalty associated w/using the function? Typically I only use
3 or 4 session vars
To: CF-Talk
Subject: RE: I don't understand session locking :(
Additionally, if you convert complex data structures into WDDX, that
will work well if your client vars are being stored in a datasource.
However, if you're using cookies as you means of storing client
variables, you'll need
Is there a performance penalty associated w/using the
function? Typically I only use 3 or 4 session vars w/simple
strings if used at all, tho' they're often duped in
application.cfm, so if I can speed things up...
I don't know if there is, but I doubt that it would be significant in any
Additionally, if you convert complex data structures into WDDX,
that will work well if your client vars are being stored in a
datasource. However, if you're using cookies as you means of
storing client variables, you'll need to be careful. Each cookie
has a limit of 4kb in size. If you
.
-Original Message-
From: Tyson [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, August 07, 2001 11:52 AM
To: CF-Talk
Subject: RE: I don't understand session locking :(
Additionally, if you convert complex data structures into WDDX, that
will work well if your client vars
Question here as well
I have done locks when ever I set a Session var.
Do I have to use a lock when ever I use the var?
i.e:
CFLOCK type=readonly scope=session
CFSET session.bgcolor = blue
/CFLOCK
body bgcolor=#session.bgcolor#
Are you saying I need to place
I have done locks when ever I set a Session var.
Do I have to use a lock when ever I use the var?
i.e:
CFLOCK type=readonly scope=session
CFSET session.bgcolor = blue
/CFLOCK
body bgcolor=#session.bgcolor#
Are you saying I need to place a lock around the
understand session locking :(
Question here as well
I have done locks when ever I set a Session var.
Do I have to use a lock when ever I use the var?
i.e:
CFLOCK type=readonly scope=session
CFSET session.bgcolor = blue
/CFLOCK
body bgcolor=#session.bgcolor#
Are you saying I need
28 matches
Mail list logo
