Re: [ACFUG Discuss] interesting issue
I'm with dean, i always put this stuff in the request scope... seems to make more sense.On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED]To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I guess but it would be nice to understand why it is really happening. Anyone have any insight? Dusty - To
Re: [ACFUG Discuss] interesting issue
sorry useless point, have you tried getting any variable from the request scope in your iframe?On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard code the datasource, username, password into the cfquery tag instead of using the variables set in application.cfm, it then runs fine in the iFrame tag. This is a band aid I
Re: [ACFUG Discuss] interesting issue
I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine...On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote:I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote:lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235DKOn 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changedwith CFMX and I'm not sure what the latest thinking is.Its beenhabit for so long I can't seem to break it.-dhsDean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the Americanpublic. -- Theodore RooseveltOn Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public.-- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the datasource, user, pass are set up in the application.cfm file. However, if I use this same query on a page that calls the page it is in from an iFrame as in: iframe src="" width=133 height=320 scrolling=Auto frameborder=0/ iframe, it won't run and throws an error: [Macromedia][SQLServer JDBC Driver][SQLServer]SELECT permission denied on object 'myTable', database 'myDataBase', owner 'dbo'. When I hard
RE: [ACFUG Discuss] interesting issue
I have no doubt that the problem must lie somewhere else From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changed with CFMX and I'm not sure what the latest thinking is.Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in an iFrame. For example (request variables are set in application.cfm): CFQUERY datasource=#request.dsnName# username=#request.dsnUser# password=#request.dsnPass#name=tracks SELECT * FROM myTable ORDER BY datestamp DESC /CFQUERY This query runs fine on its own and the
RE: [ACFUG Discuss] TEST - IGNORE
Please ignore this message. - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by http://www.fusionlink.com -
Re: [ACFUG Discuss] Restart on ## unresponsive thread
Would this help?http://www.adobe.com/devnet/server_archive/articles/cf_timeouts_and_unresponsive_requests.html http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19438TeddyOn 7/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Greetings: I'm trying to find the Restart on ## unresponsive thread setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED] -- cf_payne /http://cfpayne.wordpress.com/ - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink -
Re: [ACFUG Discuss] interesting issue
Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh? a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked.I know this changed with CFMX and I'm not sure what the latest thinking is.Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with.In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED] wrote: Yes I only have one application.cfm in the webroot and the page that is in the frame is also in the webroot. Strang one ... ??? -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of John Mason Sent: Sunday, July 23, 2006 2:28 PM To: discussion@acfug.org Subject: RE: [ACFUG Discuss] interesting issue Is the page that is in the frame on the same directory or sub directory of the application.cfm? Do you have any other application.cfm's floating around? John [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Dusty Hale Sent: Sunday, July 23, 2006 12:33 PM To: discussion@acfug.org Subject: [ACFUG Discuss] interesting issue I ran into something interesting and wondered if anyone had any insight on it. I have noticed that variables set in application.cfm, in this case in the request scope, do not work when pages are in
Re: [ACFUG Discuss] Restart on ## unresponsive thread
It's Monday. I was looking at timeout after # seconds and not restart. Where is that coffee? TeddyOn 7/24/06, Teddy Payne [EMAIL PROTECTED] wrote:The second link refers to how to do it in CFMX 6.1. Also on my development servers at work, I have this setting under CFMX 6.1 as well.I have attached a screen shot. The server I pulled it fromw as using CFMX version 6,1,0,63958.Teddy On 7/24/06, Douglas Knudsen [EMAIL PROTECTED] wrote:that setting is not available in CF 6 or . DK On 7/24/06, Teddy Payne [EMAIL PROTECTED] wrote: Would this help? http://www.adobe.com/devnet/server_archive/articles/cf_timeouts_and_unresponsive_requests.html http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_19438 TeddyOn 7/24/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Greetings: I'm trying to find the Restart on ## unresponsive thread setting in ColdFusion 7. This setting restarted the server should ## thread become unresponsive and used to be on the settings page in CF Administrator. I'm running CFMX 7.0.1 under JRun4. My server seems to reset on the 3rd unresponsive thread and I want to verify this setting. I suspect that it is in an XML setting file somewhere on the server, but I can't find it. Sincerely, Brooks Wilson Golf is an awkward set of bodily contortions designed to produce a graceful result. - Thomas D. Armour (1898-1968) Federal Reserve Bank of Atlanta · 1000 Peachtree Street, N.E. · Atlanta Georgia 30309-4470 · 404.498.8178 · fax 404.498.8239 · [EMAIL PROTECTED] -- cf_payne / http://cfpayne.wordpress.com/ - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -- Douglas Knudsen http://www.cubicleman.com this is my signature, like it? - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink - -- cf_payne / http://cfpayne.wordpress.com/ -- cf_payne /http://cfpayne.wordpress.com/ - To unsubscribe from this list, manage your profile @ http://www.acfug.org?fa=login.edituserform For more info, see http://www.acfug.org/mailinglists Archive @ http://www.mail-archive.com/discussion%40acfug.org/ List hosted by FusionLink -
Re: [ACFUG Discuss] interesting issue
You can also create multiple datasources to do the same thing. If you keep the username/password around, how do you ensure its security? CFAdmin helps, somewhat, in that regard. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] [U]nconstitutional behavior by the authorities is constrained only by the peoples' willingness to contest them --John Perry Barlow On Jul 24, 2006, at 3:47 PM, Teddy Payne wrote: One reason to do that is if the data security is being managed from the database. You can have users who have access to certain tables and stored procedures. It allows for granule level security on data. Teddy On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I don't know why I didn't notice this before but, why do you have the DSN, username and password info in the cfquery? Maybe this is causing some strange problem? I don't really get why you would send the UNAP in the query when you can just set it up in the CF Admin. On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh?a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked. I know this changed with CFMX and I'm not sure what the latest thinking is. Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice, persistent variables values that never change (like a datasource name) should be application scope and persistent variables that do change (like specific user info) should be client or session scope (client scope preferred) and that only session scope variables need locks. Do you recommend also locking client scope? These are best practices I learned years ago with Hal Helms but it has been a while and could be a little fuzzy in my head ... Dusty -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Dean H. Saxe Sent: Sunday, July 23, 2006 5:58 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Which would lead you to lock it... the REQUEST scope is fine for this sort of data. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 5:02 PM, Dusty Hale wrote: Now that I think of it since things like datasource names don't change at all ever, I should probably be using the application scope . Dusty From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] ] On Behalf Of Teddy Payne Sent: Sunday, July 23, 2006 4:45 PM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue Dusty, IFrames are buggy to begin with. In the past to overcome this, I used a more persistent scope like CLIENT or SESSION scope to persist into the IFRAME. I remember something to the effect that the loading page will get the request scope, but the IFrame is created by the browser, so that is the client browser creating the request and not the application. Teddy On 7/23/06, Dusty Hale [EMAIL PROTECTED]
Re: [ACFUG Discuss] interesting issue
A couple of things here. Multiple datasources can use different users in different roles on the same DB. SQL credentials are generally considered to be less secure than using Windows domain credentials unless you are using an encrypted DB connection. Mixed mode authentication should be disabled, generally speaking. DB auditing is only one level of auditing. Secure systems audit at multiple levels to distinct log/audit servers. One cannot depend on DB auditing in lieu of application level auditing. Both are required to truly build an effective audit trail. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] Great spirits have often encountered violent opposition from weak minds. --Einstein On Jul 24, 2006, at 4:31 PM, Teddy Payne wrote: For example in SQL Server, you create SQL users that can access only certain table and have certain roles. SQL Server stores the username and password in a nice encypted field for you when you create a SQL user. Then from ColdFusion, you use username and password on queries and stored procedures. You catch the exceptions due to lack of access to prevent users from accessing parts of your web site. Also, since you are logged using SQL credentials, you can audit the data change to the user and not the generic user used to connect to the datasource from the CF Administrator. You can do this without using SQL authentication, but why create your own audit system when the database has it built in? This is only the premise when you want user level auditing of data for regulated datasources. I just listed this example a use case of a previous client that implemented it. Most applications don't need this level of granularity. One authenticated user for the datasource works just fine. On 7/24/06, Dean H. Saxe [EMAIL PROTECTED] wrote: You can also create multiple datasources to do the same thing. If you keep the username/password around, how do you ensure its security? CFAdmin helps, somewhat, in that regard. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] [U]nconstitutional behavior by the authorities is constrained only by the peoples' willingness to contest them --John Perry Barlow On Jul 24, 2006, at 3:47 PM, Teddy Payne wrote: One reason to do that is if the data security is being managed from the database. You can have users who have access to certain tables and stored procedures. It allows for granule level security on data. Teddy On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I don't know why I didn't notice this before but, why do you have the DSN, username and password info in the cfquery? Maybe this is causing some strange problem? I don't really get why you would send the UNAP in the query when you can just set it up in the CF Admin. On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: Hmm.. i just tried this with basically your same setup... iframe calls a query to SQL server and the DSN is in the application.cfm in the request scope and it works fine. running CF 7,0,1,116466 On 7/24/06, Dusty Hale [EMAIL PROTECTED] wrote: I have no doubt that the problem must lie somewhere else … From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven Ross Sent: Monday, July 24, 2006 8:53 AM To: discussion@acfug.org Subject: Re: [ACFUG Discuss] interesting issue I just tested creating a dummy query in my application cfm and dumping it in my iframe and it worked fine... On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: sorry useless point, have you tried getting any variable from the request scope in your iframe? On 7/24/06, Steven Ross [EMAIL PROTECTED] wrote: I'm with dean, i always put this stuff in the request scope... seems to make more sense. On 7/23/06, Douglas Knudsen [EMAIL PROTECTED] wrote: lock if a race condition is expected, eh?a DSN setting that is never expeced to change on a regular basis wouldn't need a lock. But if other things are being set/read in a shared scope ( frames can be suspect here) locking may need to be used. http://www.adobe.com/cfusion/knowledgebase/index.cfm?id=tn_18235 DK On 7/23/06, Dean H. Saxe [EMAIL PROTECTED] wrote: Shared scope variables are generally locked. I know this changed with CFMX and I'm not sure what the latest thinking is. Its been habit for so long I can't seem to break it. -dhs Dean H. Saxe, CISSP, CEH [EMAIL PROTECTED] To announce that there must be no criticism of the president, or that we are to stand by the president right or wrong, is not only unpatriotic and servile, but is morally treasonable to the American public. -- Theodore Roosevelt On Jul 23, 2006, at 6:29 PM, Dusty Hale wrote: Why would an application scope variable need to be locked (it never changes)? I was always under the assumption that only session scope variables need to be locked. I could have this wrong but I thought as a best practice,
