RE: Variable locking
Hi I'm joining this thread late. Can I just confirm what you guys are saying: In CFMX named locks should be used in place of scoped locks and locks are only needed When a possible race condition could occur? Thanks Kola -Original Message- From: Sean A Corfield [mailto:[EMAIL PROTECTED]] Sent: 04 October 2002 22:53 To: CF-Talk Subject: Re: Variable locking On Friday, Oct 4, 2002, at 12:07 US/Pacific, Gaulin, Mark wrote: Actually, that using NAME is not a better practice... the SCOPE attribute is safer and is also what MM support advised us to use (when applicable). Pre-MX. Sure, the scope of a NAME-based lock will be tighter than using SCOPE, but SCOPE will be safer and, as a bonus, you can use CF 5's (and prior) auto-checking for missing locks... Which is no longer available in MX because it is no longer needed. Basically, NAME is older than SCOPE, and SCOPE was added to address issues that NAME cannot handle. SCOPE was added to resolve bugs in earlier releases of CF around the shared scope memory corruption problems. That is no longer an issue in CFMX. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Re: Variable locking
On Monday, Oct 7, 2002, at 01:38 US/Pacific, Kola Oyedeji wrote: I'm joining this thread late. Can I just confirm what you guys are saying: In CFMX named locks should be used in place of scoped locks and locks are only needed When a possible race condition could occur? The last part is relatively easy to answer: yes, you only need locks when a race condition could occur. The first part is slightly harder to answer: in general, named locks allow finer grained control over locking and therefore will cause fewer lock contentions between requests. Consider a couple of variables in server scope: in CF5 (and earlier) you had to use scope=server to protect access to such variables so any code accessing one of those variables would block any code accessing the other variable. In CFMX, it is safe to use a named lock instead, with a different lock name for each variable: !--- page1.cfm : CF5 scoped lock --- cflock scope=server type=exclusive cfset server.a = 42 /cflock !--- page2.cfm : CF5 scoped lock --- cflock scope=server type=exclusive cfset server.b = 77 /cflock While page1.cfm is executing, page2.cfm would block. In CFMX you can do this: !--- page1.cfm : CFMX named lock --- cflock scope=server_a type=exclusive cfset server.a = 42 /cflock !--- page2.cfm : CFMX named lock --- cflock scope=server_b type=exclusive cfset server.b = 77 /cflock Now the pages won't block each other (obviously multiple requests to page1.cfm will block each other but page2.cfm wouldn't be affected). That's easy enough for application and server scope because the name is easy to figure out. For session scope, you need a name that is unique to your session which may be harder to invent (you could perhaps use a user ID if it exists or a per-session UUID). OTOH, race conditions within session scope are probably going to be rarer because they can only occur if you have multiple windows or frames open with the same session data (frames are evil, in my opinion, so I'm not very sympathetic to people who get into a session integrity mess when they use frames! :) If it's too hard to come up with a unique name for your lock, using scope= may be the easiest solution for you. Since the shared scope corruption problem is no longer an issue in CFMX, there are many cases where you safely omit the lock altogether (for example, if the assignment is 'atomic' and all request would store the same value - or it doesn't matter which request actually stores the value, e.g., the application just needs *a* value in the shared scope variable). Hope that helps clarify? An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
RE: Variable locking
For session scope, you need a name that is unique to your session which may be harder to invent (you could perhaps use a user ID if it exists or a per- session UUID). If I recall correctly, the MM recommended naming scheme for CF 4.01 would work fine here - use the concatenation of CFID and CFTOKEN. OTOH, race conditions within session scope are probably going to be rarer because they can only occur if you have multiple windows or frames open with the same session data I think that you can run into contention issues without multiple windows or frames within the session scope, but they do tend to be rare. I've seen situations where it appeared that heavy server load, fast network connections, and CFLOCATION would cause the same sort of problem. (frames are evil, in my opinion, so I'm not very sympathetic to people who get into a session integrity mess when they use frames! :) s/frames/Flash ? Technology is ... technology. Poorly-implemented technology is bad, but that's not an argument against the technology itself. I've seen plenty of cases where frames enhanced the functionality of a web application. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: Variable locking
For session scope, you need a name that is unique to your session which may be harder to invent (you could perhaps use a user ID if it exists or a per- session UUID). If I recall correctly, the MM recommended naming scheme for CF 4.01 would work fine here - use the concatenation of CFID and CFTOKEN. And don't forget you can make that even easier by using the URLTOKEN variable. === Raymond Camden, ColdFusion Jedi Master for Hire Email: [EMAIL PROTECTED] WWW : www.camdenfamily.com/morpheus Yahoo IM : morpheus My ally is the Force, and a powerful ally it is. - Yoda ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
Re: Variable locking
Yup (on CF5, good practice on CFMX but not required) cflock timeout=20 throwontimeout=No type=READONLY scope=SESSION cfoutput#session.fullname#/cfoutput /cflock Do this at the top of the page: cflock timeout=20 throwontimeout=No type=READONLY scope=SESSION cfset variables.fullname = session.fullname /cflock Then you can play with it all page long without any locks cfoutput#variables.fullname#/cfoutput But if you modify it at all throughout the page, you will want to do the following at the bottom of the page: cflock timeout=20 throwontimeout=No type=EXCLUSIVE scope=SESSION cfset session.fullname = variables.fullname /cflock Hope this helps! Paul Giesenhagen QuillDesign - Original Message - From: Luis Lebron [EMAIL PROTECTED] To: CF-Talk [EMAIL PROTECTED] Sent: Friday, October 04, 2002 1:16 PM Subject: Variable locking I have a question on Session variables. If I have a statement like cfoutput#Session.Fullname#/cfoutput do I need to use cflock tags with it? thanks, Luis ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
RE: Variable locking
Prior to MX, the rule is very simple: If you type session, or server, or application, you need a lock. Period. I don't care how you are using it. Lock it. In MX, if there is no danger of fullname being changed by another process, or if you don't care, don't worry about the lock. === Raymond Camden, ColdFusion Jedi Master for Hire Email: [EMAIL PROTECTED] WWW : www.camdenfamily.com/morpheus Yahoo IM : morpheus My ally is the Force, and a powerful ally it is. - Yoda -Original Message- From: Luis Lebron [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:17 PM To: CF-Talk Subject: Variable locking I have a question on Session variables. If I have a statement like cfoutput#Session.Fullname#/cfoutput do I need to use cflock tags with it? thanks, Luis ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Variable locking
On Friday, Oct 4, 2002, at 11:37 US/Pacific, Paul Giesenhagen wrote: Yup (on CF5, good practice on CFMX but not required) cflock timeout=20 throwontimeout=No type=READONLY scope=SESSION cfoutput#session.fullname#/cfoutput /cflock Better practice: cflock timeout=20 throwontimeout=No type=READONLY name=session_fullname cfoutput#session.fullname#/cfoutput /cflock Using a named lock instead of a scoped lock. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Get the mailserver that powers this list at http://www.coolfusion.com
RE: Variable locking
Actually, that using NAME is not a better practice... the SCOPE attribute is safer and is also what MM support advised us to use (when applicable). Sure, the scope of a NAME-based lock will be tighter than using SCOPE, but SCOPE will be safer and, as a bonus, you can use CF 5's (and prior) auto-checking for missing locks... that doesn't work if you use the NAME version to try to protect the session, application, etc scopes. (Note: I only use the auto-checking on a development machine.) Basically, NAME is older than SCOPE, and SCOPE was added to address issues that NAME cannot handle. NAME still has a place though, since there are other kinds of locking you may need to do that SCOPE is inappropriate for. Mark -Original Message- From: Sean A Corfield [mailto:[EMAIL PROTECTED]] Sent: Friday, October 04, 2002 2:46 PM To: CF-Talk Subject: Re: Variable locking On Friday, Oct 4, 2002, at 11:37 US/Pacific, Paul Giesenhagen wrote: Yup (on CF5, good practice on CFMX but not required) cflock timeout=20 throwontimeout=No type=READONLY scope=SESSION cfoutput#session.fullname#/cfoutput /cflock Better practice: cflock timeout=20 throwontimeout=No type=READONLY name=session_fullname cfoutput#session.fullname#/cfoutput /cflock Using a named lock instead of a scoped lock. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Variable locking
On Friday, Oct 4, 2002, at 11:37 US/Pacific, Paul Giesenhagen wrote: Yup (on CF5, good practice on CFMX but not required) cflock timeout=20 throwontimeout=No type=READONLY scope=SESSION cfoutput#session.fullname#/cfoutput /cflock Better practice: cflock timeout=20 throwontimeout=No type=READONLY name=session_fullname cfoutput#session.fullname#/cfoutput /cflock Using a named lock instead of a scoped lock. Doesn't this tie the performance of all applications on the server together when they reference the session_fullname lock? Isaac Certified Advanced ColdFusion 5 Developer www.turnkey.to 954-776-0046 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting.
RE: Variable locking
Actually, that using NAME is not a better practice... the SCOPE attribute is safer and is also what MM support advised us to use (when applicable). This is true for versions prior to CF MX. For those versions, you should use the SCOPE attribute. Sean's point is only applicable to CF MX, in which you only lock to prevent logical errors - in that case, you want your lock to be as small as possible in its scope, and using the NAME attribute allows you to do that. Dave Watts, CTO, Fig Leaf Software http://www.figleaf.com/ voice: (202) 797-5496 fax: (202) 797-5444 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Variable locking
On Friday, Oct 4, 2002, at 14:27 US/Pacific, Dave Watts wrote: This is true for versions prior to CF MX. For those versions, you should use the SCOPE attribute. Sean's point is only applicable to CF MX, in which you only lock to prevent logical errors - in that case, you want your lock to be as small as possible in its scope, and using the NAME attribute allows you to do that. Yes, I should have been clearer. My comment was for MX only. The CF product team recommend using named locks in CFMX instead of scoped locks. I no longer have the email to hand that explains all the reasons but, apart from narrowing the zone of the lock, CF has some built in machinery for detecting named lock conflicts that does not apply to scoped locks. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Your ad could be here. Monies from ads go to support these lists and provide more resources for the community. http://www.fusionauthority.com/ads.cfm
Re: Variable locking
On Friday, Oct 4, 2002, at 12:07 US/Pacific, Gaulin, Mark wrote: Actually, that using NAME is not a better practice... the SCOPE attribute is safer and is also what MM support advised us to use (when applicable). Pre-MX. Sure, the scope of a NAME-based lock will be tighter than using SCOPE, but SCOPE will be safer and, as a bonus, you can use CF 5's (and prior) auto-checking for missing locks... Which is no longer available in MX because it is no longer needed. Basically, NAME is older than SCOPE, and SCOPE was added to address issues that NAME cannot handle. SCOPE was added to resolve bugs in earlier releases of CF around the shared scope memory corruption problems. That is no longer an issue in CFMX. An Architect's View -- http://www.corfield.org/blog/ Macromedia DevCon 2002, October 27-30, Orlando, Florida Architecting a New Internet Experience Register today at http://www.macromedia.com/go/devcon2002 ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
Re: Variable locking
Dave is right (as usual)... As I understand it, locking in MX is still recommended when you have a possible race condition... EXAMPLE: SESSION.myCount = SESSION.myCount + 1 You could still potentially have problems in this situation even in MX. -Michael Conger [EMAIL PROTECTED] - Original Message - From: Luis Lebron [EMAIL PROTECTED] Newsgroups: cf-talk Sent: Friday, October 04, 2002 2:16 PM Subject: Variable locking I have a question on Session variables. If I have a statement like cfoutput#Session.Fullname#/cfoutput do I need to use cflock tags with it? thanks, Luis ~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=listsbody=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
RE: variable locking and transactions
here you go, it was given to me Monday from this listdave whiterod I think ;) You may find the following link useful: ColdFusion Server (Versions 5 and Prior): ColdFusion Locking Best Practices TechNote 20370 http://www.macromedia.com/v1/handlers/index.cfm?ID=20370Method=Full also, from dave watts The thought process is very simple. If you're running CF 5 or earlier, and you're using session variables, and you don't lock them, bad things will happen. Memory variables can be accessed by concurrent requests, and CF doesn't handle that well, by default. While you might not think session variables would be used by concurrent requests, there are many possible cases in which more than one request from the same user might be running concurrently. any good books on that topic? A book would be overkill, just for this topic. If you're using CF 5 or earlier, just follow these simple rules: 1. Dvery time you put Session, Application or Server in your code, use CFLOCK around it. 2. If you're using any version of CF which supports the SCOPE attribute (4.5+, I think), use that with your CFLOCK tags around memory variables. 3. If you're reading a memory variable, use TYPE=READONLY in your CFLOCK; if you may change the variable's value, use TYPE=EXCLUSIVE. 4. There is no rule 4. 5. Reread rule 1. ..tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Pablo Nevares [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 2:56 PM To: CF-Talk Subject: variable locking and transactions I've been looking up information on cflock and cftransaction lately, I'm sad to say that I haven't had any experience using them in the past. Am I correct in saying that as a best practice cflock should always be used when you're accessing or modifying variables in Session, Application, or Server scopes? And you use the ReadOnly type when you're only going to access the variable, and exclusive when there's any chance it'll be modified? I'm a little more confused about cftransaction. I understand that you can either commit or rollback queries with it, but is this also how you lock databases? If I don't want two people inserting new records into the database at once, would I just do a normal cftransaction with a commit at the end? Thanks in advance for any help. Pablo Nevares [EMAIL PROTECTED] __ This list and all House of Fusion resources hosted by CFHosting.com. The place for dependable ColdFusion Hosting. 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: variable locking and transactions
Thank you for the information. That explains a lot. Does anybody have tips on the database locking part? Pablo Nevares [EMAIL PROTECTED] Information Technology Hendricks Partners -Original Message- From: Tony Weeg [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 11:58 AM To: CF-Talk Subject: RE: variable locking and transactions here you go, it was given to me Monday from this listdave whiterod I think ;) You may find the following link useful: ColdFusion Server (Versions 5 and Prior): ColdFusion Locking Best Practices TechNote 20370 http://www.macromedia.com/v1/handlers/index.cfm?ID=20370Method=Full also, from dave watts The thought process is very simple. If you're running CF 5 or earlier, and you're using session variables, and you don't lock them, bad things will happen. Memory variables can be accessed by concurrent requests, and CF doesn't handle that well, by default. While you might not think session variables would be used by concurrent requests, there are many possible cases in which more than one request from the same user might be running concurrently. any good books on that topic? A book would be overkill, just for this topic. If you're using CF 5 or earlier, just follow these simple rules: 1. Dvery time you put Session, Application or Server in your code, use CFLOCK around it. 2. If you're using any version of CF which supports the SCOPE attribute (4.5+, I think), use that with your CFLOCK tags around memory variables. 3. If you're reading a memory variable, use TYPE=READONLY in your CFLOCK; if you may change the variable's value, use TYPE=EXCLUSIVE. 4. There is no rule 4. 5. Reread rule 1. .tony Tony Weeg Senior Web Developer Information System Design Navtrak, Inc. Fleet Management Solutions www.navtrak.net 410.548.2337 -Original Message- From: Pablo Nevares [mailto:[EMAIL PROTECTED]] Sent: Tuesday, September 24, 2002 2:56 PM To: CF-Talk Subject: variable locking and transactions I've been looking up information on cflock and cftransaction lately, I'm sad to say that I haven't had any experience using them in the past. Am I correct in saying that as a best practice cflock should always be used when you're accessing or modifying variables in Session, Application, or Server scopes? And you use the ReadOnly type when you're only going to access the variable, and exclusive when there's any chance it'll be modified? I'm a little more confused about cftransaction. I understand that you can either commit or rollback queries with it, but is this also how you lock databases? If I don't want two people inserting new records into the database at once, would I just do a normal cftransaction with a commit at the end? Thanks in advance for any help. Pablo Nevares [EMAIL PROTECTED] __ 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
