3

群众的问题。我们对我们的团队在 CFC 中的函数内限定局部变量的范围非常严格。最近,虽然 Application.cfc 中的范围变量问题出现了。像 onRequestStart() 这样的函数中的非作用域变量是否存在被同时运行的其他会话访问的相同风险,因为我们知道其他组件中的函数中的局部变量是?还是因为 Application.cfc 中函数的性质而对它们进行了不同的处理?

4

1 回答 1

13

您的问题与两个完全独立的问题接壤(这两个问题对于澄清和解决都很重要)。这两个问题是:

  1. 在引用它们时,我是否应该正确地确定变量的范围(即 APPLICATION.settings 与 SESSION.settings)。

对此的简短回答是:的。它使代码更清晰、更易读/更易于管理,并防止您稍后在重用变量名时可能遇到的变量范围冲突。

如果您创建 APPLICATION.settings 和 SESSION.settings,但尝试在没有范围的情况下引用它们(即。<cfset myvar = settings />),您将遇到变量冲突问题,因为默认情况下它们将被倒入 VARIABLES 中——因为既不是 APPLICATION 也不是检查 SESSION 以解决范围模糊性。

第二个问题是:

  1. 我是否应该担心在 Application.cfc 中访问的变量可能被并发环境中的多个用户共享?

对此的简短回答是:的。您应该了解并了解如何访问共享变量的后果,以及<CFLOCK>在适当的情况下使用它们的后果。

不幸的是,您锁定共享变量的确切时间和地点通常永远不会向 CF 社区澄清,所以让我总结一下:

  1. onApplicationStart() 单线程访问 APPLICATION 范围。您不需要锁定在此方法中读取/写入的 APPLICATION 变量。
  2. onSessionStart() 单线程访问 SESSION 范围。和以前一样的答案。
  3. 如果您提供从 onRequestStart() 方法中访问 SESSION 或 APPLICATION 的任何类型的机制——或之后的任何其他模板(例如直接调用 onApplicationStart() 的 URL 重新加载参数)——所有的赌注都没有——你必须现在可以正确处理共享变量读写的锁定。
于 2011-11-18T19:49:45.433 回答