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 should have coded that function into it's core design. Dennis Powers UXB Internet (203)879-2844 http://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 as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 lock around a block of code. -Original Message- From: Dennis Powers [mailto:[EMAIL 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 should have coded that function into it's core design. Dennis Powers UXB Internet (203)879-2844 http://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 as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 should have coded that function into it's core design. Maybe so. I can't speak to that, since I don't know enough about the internals of the CF server. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
You make a very good point. My field experience on many different sites is deal with locking in the development/qa phase. Watch the Application and Server logs religiously and lock code as identified in these logs. Also watch the Application and Server logs on the live servers and lock code as identified in these logs. The bottom line is check these logs at least daily and whittle down the errors. I do not subscribe to the lock-everything school of thought and this is from direct real-world experience. Kind Regards - Mike Brunt Tel: 562.790.8631 Instant Messaging Handles: - AIM (AOL): 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 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. Dennis Powers UXB Internet (203)879-2844 http://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 as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
I agree. It makes more sense to not auto-lock because you have more control over how/where you do your locking. Over time and traffic, locking can cause its own major headaches. Plus, if you turn on the CF Admin option that does auto-locking, you'll see a noticeable performance hit on your server if you're getting high volumes of traffic. The locking and unlocking requires a bit of CF performance. It's a pain in the butt sometimes, but overall it's usually not too bad to do your own locking. -Tyson -Original Message- From: Matthew W Jones [mailto:[EMAIL PROTECTED]] Sent: 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 lock around a block of code. -Original Message- From: Dennis Powers [mailto:[EMAIL 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 should have coded that function into it's core design. Dennis Powers UXB Internet (203)879-2844 http://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 as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
What exactly are you looking for in the logs? My understanding of inadequate locking was that memory and variable corruption were the problems, which might not be clear in the logs. thanks, Chris Norloff -- Original Message -- from: Mike Brunt [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] date: Thu, 09 Aug 2001 08:16:43 -0700 You make a very good point. My field experience on many different sites is deal with locking in the development/qa phase. Watch the Application and Server logs religiously and lock code as identified in these logs. Also watch the Application and Server logs on the live servers and lock code as identified in these logs. The bottom line is check these logs at least daily and whittle down the errors. I do not subscribe to the lock-everything school of thought and this is from direct real-world experience. Kind Regards - Mike Brunt Tel: 562.790.8631 Instant Messaging Handles: - AIM (AOL): 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 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. Dennis Powers UXB Internet (203)879-2844 http://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 as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 ONLY when dealing with complex variables. Thus, cfset request.variablename = session.variablename would work fine as long as session.variablename is not complex. NOT SO, says MM Tech Support. Seems like cfset ALWAYS sets a pointer rather than making a copy when dealing with shared-scope variables (session, application, server). I gotta test this out, 'cause we've been having some real serious variable vanishes problems, and this could be it. Sure wish CF worked like it's documented to work. Chris Norloff -- Original Message -- from: David Shadovitz [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] date: Tue, 07 Aug 2001 11:04:21 -0700 But these variables are simple strings (I think str here means string, not structure). There's no need to use Duplicate() for simple CFML variables. You may want to use Duplicate() on the entire Session structure, but not on a string. -David On Tuesday, August 07, Matthew W Jones [SMTP:[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? 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 Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: 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 ONLY when dealing with complex variables. Thus, cfset request.variablename = session.variablename would work fine as long as session.variablename is not complex. NOT SO, says MM Tech Support. Seems like cfset ALWAYS sets a pointer rather than making a copy when dealing with shared-scope variables (session, application, server). There are three possibilities. 1. You misunderstood what MM tech support said, or 2. MM tech support misunderstood what you were asking, or 3. MM tech support needs to implement drug testing. It's very easy to test the above statement. cfset Application.bar = baz cfset Variables.bar = Application.bar cfset Application.bar = foo cfoutput#Variables.bar#/cfoutput If the variable within the Application scope was passed by reference to the local scope, the output should be foo, but when I ran it, it was baz. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ phone: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: cfset and/or Duplicate() [was:RE: I don't understand session locking :(
here is a test of simple complex values. That statement that the rep told you is false. HTH, Robert Hinojosa [EMAIL PROTECTED] 972.243.4343 x7446 cflock scope=session type=exclusive timeout=4 !--- SIMPLE VALUES Passed by value, no duplicate needed.--- cfset session.a = I am A, not B cfset b = empty cfoutputliB:#b#/cfoutput cfset b = session.a cfset session.a = If B was a pointer, I would be showing cfoutputliB: #b#/cfoutput !--- Complex Structure, Duplicate needed --- cfset session.test2 = structNew() cfset session.test2.a = structNew() cfset session.test2.a.str = I am a nested complex structure cfset referenceStruct = structNew() cfset valueStruct = Duplicate(session.test2.a) cfset referenceStruct = session.test2.a cfoutput li REFERENCE STRUCT: #referenceStruct.str# li VALUE STRUCT:#valueStruct.str# cfset session.test2.a.str = No longer a nested complex structure, but a pointer li REFERENCE STRUCT: #referenceStruct.str# li VALUE STRUCT: #valueStruct.str# /cfoutput /cflock -Original Message- From: 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 ONLY when dealing with complex variables. Thus, cfset request.variablename = session.variablename would work fine as long as session.variablename is not complex. NOT SO, says MM Tech Support. Seems like cfset ALWAYS sets a pointer rather than making a copy when dealing with shared-scope variables (session, application, server). I gotta test this out, 'cause we've been having some real serious variable vanishes problems, and this could be it. Sure wish CF worked like it's documented to work. Chris Norloff -- Original Message -- from: David Shadovitz [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] date: Tue, 07 Aug 2001 11:04:21 -0700 But these variables are simple strings (I think str here means string, not structure). There's no need to use Duplicate() for simple CFML variables. You may want to use Duplicate() on the entire Session structure, but not on a string. -David On Tuesday, August 07, Matthew W Jones [SMTP:[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? 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 Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
There's an easy technique to avoid excessive locking with any shared scope (application, server, session) variables. Rather than locking the variables all over the place, simply lock them once, make a copy of them into the request scope, and use those. Here's a code example where this would save you much locking headache. !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock !--- if the user has an email address in their session --- cfif len(trim(request.session.strEmail)) !--- print their name with a link --- cfoutput a href=mailto:#request.session.strEmail#;#request.session.strFirstName# #request.session.strLastName#/a /cfoutput cfelse !--- otherwise, just print the name --- cfoutput #request.session.strFirstName# #request.session.strLastName# /cfoutput /cfif As you can see, by using the copy of the value I made into the request scope, I now no longer need to lock all the read I did when printing the user's name and email address. Of course, if you wanted to change the value of the session variables, you'd still need to do an exclusive lock and change the actual session variable. Changing the request.session.strEmail in this example would have NO effect on the actual session.strEmail variable. It's a best practice to have as little code as possible between CFLOCK tags just as a precaution. If you have CFLOCK tags around more than 10 lines of code, you should re-evaluate and see if there's an easier way to write the same code with out locking so much of it and still following the best practice of locking shared scope variables. Hope this helps, Tyson Tyson Vanek, Technical Lead duoDesign, The eBusiness Architects Building your business online 847.491.3000 main | [EMAIL PROTECTED] 847.491.3100 fax | www.duodesign.com 847.491.4270 direct | www.chicagoangels.org Come to our free 2-hour seminar The eBusiness Squeeze http://www.duodesign.com/squeeze/seminar.html -Original Message- From: Bruce, Rodney [mailto:[EMAIL PROTECTED]] Sent: Monday, August 06, 2001 6:00 PM To: CF-Talk 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=#session.bgcolor# Are you saying I need to place a lock around the body tag? ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 actually only created a pointer to the session variable and left you vulnerable to the locking issue. Using Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 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 Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 leaves your site with out logging out? ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
But these variables are simple strings (I think str here means string, not structure). There's no need to use Duplicate() for simple CFML variables. You may want to use Duplicate() on the entire Session structure, but not on a string. -David On Tuesday, August 07, Matthew W Jones [SMTP:[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? 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 Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 actually only created a pointer to the session variable and left you vulnerable to the locking issue. Using Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # If you're only copying variables containing simple values (strings, essentially), those variables will be passed by value, meaning that when you copy the variable, you end up with two separate variables. Queries and structures - complex data objects - are passed by reference, meaning that when you copy the variable, you end up with two pointers to the same underlying data object. When copying queries and structures, you may need to use Duplicate; when copying strings, it's unnecessary. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 PROTECTED] date: Tue, 07 Aug 2001 11:04:21 -0700 But these variables are simple strings (I think str here means string, not structure). There's no need to use Duplicate() for simple CFML variables. ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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. However, there will be a lot more overhead in doing this - the Client scope is inherently more expensive to use. So, if you've got an application which uses Session variables all over the place, you might have problems if you simply switch to Client variables. You'd have to go through the application and decide what you can do without when storing persistent data. Looking at the table, cdata, the client vars are all dumped into one field, can this be changed? No. You're free to build your own alternative state management mechanism, though; this is what we all used to do before Client and Session variables anyway - you'd design the appropriate relational database structure, and store your data in there, and simply retrieve it on each page request using a regular SQL statement. and is there a way to automatically delete them when a user leaves your site with out logging out? Not really, since you don't know when someone leaves your site. All you know is that it's been a certain period of time since their last page request. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 simple variable contained within a structure by value, you don't need to use Duplicate. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 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 Duplicate(), however, made a true clone of the variable that was free from the locking issues. As in. cfset request.session.strFirstName = Duplicate(session.strFirstName) # !--- lock session and read name/email address --- cflock scope=session type=readonly timeout=30 cfset request.session.strFirstName = session.strFirstName cfset request.session.strLastName = session.strLastName cfset request.session.strEmail = session.strEmail /cflock # ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 to be careful. Each cookie has a limit of 4kb in size. If you start 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 :( 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. However, there will be a lot more overhead in doing this - the Client scope is inherently more expensive to use. So, if you've got an application which uses Session variables all over the place, you might have problems if you simply switch to Client variables. You'd have to go through the application and decide what you can do without when storing persistent data. Looking at the table, cdata, the client vars are all dumped into one field, can this be changed? No. You're free to build your own alternative state management mechanism, though; this is what we all used to do before Client and Session variables anyway - you'd design the appropriate relational database structure, and store your data in there, and simply retrieve it on each page request using a regular SQL statement. and is there a way to automatically delete them when a user leaves your site with out logging out? Not really, since you don't know when someone leaves your site. All you know is that it's been a certain period of time since their last page request. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 w/simple strings if used at all, tho' they're often duped in application.cfm, so if I can speed things up... --Matt-- -- Original Message -- from: Dave Watts [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] date: Tue, 07 Aug 2001 14:45:22 -0400 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 simple variable contained within a structure by value, you don't need to use Duplicate. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
thanks for all the info and help See if I can do a sum here. Session Vars are faster(memery vs db), but do use up server RAM. less overall overhead but you have to use CFLOCK every time a session var is referenced to help avoid corruption of data(which itself can then cause a performance drop). But can handle complex data types better(?) Client Vars are a little slower(db request), but don't use up server RAM. Can have a lot more overhead, specially if dealing with Structures or Arrays. Don't have to use CFLOCK when referencing. Data is a lot more secure. But have to write procedures to clean up db. Again thanks for all the help. I think I understand a lot more and hope the individual that started this thread also did. -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 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 start 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 :( 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. However, there will be a lot more overhead in doing this - the Client scope is inherently more expensive to use. So, if you've got an application which uses Session variables all over the place, you might have problems if you simply switch to Client variables. You'd have to go through the application and decide what you can do without when storing persistent data. Looking at the table, cdata, the client vars are all dumped into one field, can this be changed? No. You're free to build your own alternative state management mechanism, though; this is what we all used to do before Client and Session variables anyway - you'd design the appropriate relational database structure, and store your data in there, and simply retrieve it on each page request using a regular SQL statement. and is there a way to automatically delete them when a user leaves your site with out logging out? Not really, since you don't know when someone leaves your site. All you know is that it's been a certain period of time since their last page request. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 case. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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 to be careful. Each cookie has a limit of 4kb in size. If you start dealing with complex nested data structures in WDDX, it's very easy to bump over 4kb in size with a WDDX packet. Even if you're storing client variables in a database, you still want to avoid storing complex data objects unnecessarily. If you don't, your application will perform a lot slower using client variables than it would with the same data objects in session variables. I've seen this happen a couple of times; someone will have an application which stores lots of data in the Session scope, they'll convert it to the Client scope so that the application can be load-balanced, and it'll essentially fail under load due to the database traffic. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
One more important thing to keep in mind. Session variables don't work in a non-sticky clustered environment where you hit a different server on every request. If you want to implement session variables on a cluster, the cluster must be setup in sticky mode (meaning that you hit a random server the first time, but maintain tied to that server for the life of the session). Kevin [EMAIL PROTECTED] 08/07/01 12:37PM thanks for all the info and help See if I can do a sum here. Session Vars are faster(memery vs db), but do use up server RAM. less overall overhead but you have to use CFLOCK every time a session var is referenced to help avoid corruption of data(which itself can then cause a performance drop). But can handle complex data types better(?) Client Vars are a little slower(db request), but don't use up server RAM. Can have a lot more overhead, specially if dealing with Structures or Arrays. Don't have to use CFLOCK when referencing. Data is a lot more secure. But have to write procedures to clean up db. Again thanks for all the help. I think I understand a lot more and hope the individual that started this thread also did. -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 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 start 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 :( 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. However, there will be a lot more overhead in doing this - the Client scope is inherently more expensive to use. So, if you've got an application which uses Session variables all over the place, you might have problems if you simply switch to Client variables. You'd have to go through the application and decide what you can do without when storing persistent data. Looking at the table, cdata, the client vars are all dumped into one field, can this be changed? No. You're free to build your own alternative state management mechanism, though; this is what we all used to do before Client and Session variables anyway - you'd design the appropriate relational database structure, and store your data in there, and simply retrieve it on each page request using a regular SQL statement. and is there a way to automatically delete them when a user leaves your site with out logging out? Not really, since you don't know when someone leaves your site. All you know is that it's been a certain period of time since their last page request. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
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=#session.bgcolor# Are you saying I need to place a lock around the body tag? ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
RE: I don't understand session locking :(
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 body tag? Yes, you need to place a lock around any reads or writes of Session variables. If you don't lock reads as well as writes, and there's any possibility of the two operations happening simultaneously (and there usually is), then the lock you put on the write is useless by itself. Locking in CF (and in databases as well) is essentially a cooperative venture. Placing one lock on one piece of code doesn't do any good if another piece of code accesses the resource without a lock. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
Re: I don't understand session locking :(
body bgcolor=#session.bgcolor# Are you saying I need to place a lock around the body tag? Yep. Simple rule .. you should always lock a session variable whenever it is used. :) For this reason, I prefer and reccomend, Client variables (stored in a database), but if you have an app where perfomance isn't a major issue, and you don't plan on ever having to move it to a clustered environment, then Session variables will be fine. Todd - Original Message - From: Bruce, Rodney [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Monday, August 06, 2001 6:59 PM 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=#session.bgcolor# Are you saying I need to place a lock around the body tag? ~~ Structure your ColdFusion code with Fusebox. Get the official book at http://www.fusionauthority.com/bkinfo.cfm FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Archives: http://www.mail-archive.com/cf-talk@houseoffusion.com/ Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
