【问题标题】:How RedShift Sessions are handled from a Server Connection for TEMP tables如何从 TEMP 表的服务器连接处理 RedShift 会话
【发布时间】:2016-05-20 15:21:24
【问题描述】:

我正在使用 ColdFusion 连接到 RedShift 数据库,并且我正在尝试了解如何测试/假设自己如何连接与 RedShift 中的 TEMP 表相关的工作。

  1. 在我的数据源的 CFADMIN 中,我 未选中 Maintain connections across client requests。我会假设每个使用我的网站的用户都有自己的数据库“连接”?对吗?

  2. 根据有关临时表的 RedShift 文档:

TEMP:创建仅在当前会话中可见的临时表的关键字。该表在创建它的会话结束时自动删除。临时表可以与永久表同名。临时表是在单独的、特定于会话的模式中创建的。 (您不能为此架构指定名称。)此临时架构成为搜索路径中的第一个架构,因此临时表将优先于永久表,除非您使用架构名称限定表名以访问永久表。

我是否理解如果 #1 为真,并且每个用户都有自己的数据库连接,因此每个用户都有自己的会话,那么每个 #2 创建的任何表都将仅在该会话中,即使“用户”是与来自我的服务器的连接使用相同的凭据相同。

3.如果我在 #1 和 #2 中的假设是正确的,那么如果我有运行如下查询的 ColdFusion 代码:

drop if exists tablea
create temp table tablea
insert into tablea
select * from realtable inner join
drop tablea

并且多个用户正在使用执行此操作的相同功能。他们不应该遇到任何冲突,即一个表被删除,因为另一个请求试图正确使用它?

  1. 如何测试是否是这种情况?除了将其投入生产并等待错误之外,我怎么知道。我尝试在不同的浏览器和其他东西中并排运行几个窗口,但没有发现问题,但我不知道如何知道客户端之间的临时表是否真的不同。 (应该如此。)我想我可以查询一些元数据,但是关于表的哪些元数据会告诉我呢?

【问题讨论】:

  • 当我查询 stv_sessions 时,我可以看到我的用户名有多个会话。
  • 免责声明,我不熟悉红移,但您描述的是(非全局)临时表在 SQL Server 等数据库中的行为方式。同一个“用户”可以创建多个会话,但在一个会话中创建的临时表对其他会话不可见。不确定这是否有帮助,但[此线程提到检查 STV_TBL_PERM](BNohttp://stackoverflow.com/questions/24561837/conditionally-drop-temporary-table-in-redshift)。
  • 你知道从服务器到数据库的连接吗?我谈到的 CF 中的设置似乎表明每个客户端请求(不确定该定义是什么)都会有一个唯一的连接,因此是唯一的会话,对吗?
  • 正确。当“维护连接”被禁用时,每个请求都应该创建一个新的连接,这构成一个单独的数据库“会话”。
  • 如果这是真的,那么我假设单个会话处于活动状态并且 CF 保持打开状态,直到特定用户超时。所以usera 登录我的应用程序并积极使用它一个小时。他们本可以只开一个小时的课程。 userb 登录我的应用程序,每 25 分钟才处理一次。由于我的数据源连接超时时间为 20 分钟,因此他们每次都会有不同的数据库会话。

标签: coldfusion amazon-redshift


【解决方案1】:

我也有类似的情况,但是用的是redbrick 数据库软件。我通过创建唯一的表名来处理它。总体思路是:

  1. 创建一个类似这样的表名:

    <cfset tablename = TableText & randrange(1, 100000)>
    
  2. 尝试使用该名称创建表。如果失败,请使用其他名称重试。

  3. 如果您失败了 3 次,请停止尝试并将 cfcatch 信息邮寄给某人。

我将所有这些代码放在一个自定义标签中。

编辑从这里开始

根据 cmets,这里有一些关于我的情况的更多信息。在 CFAdmin 中,对于正在讨论的数据源,选中了“维护连接”框。

我将此代码放在 ColdFusion 页面上:

<cfquery datasource="dw">
create temporary table dan (f1 int)
</cfquery>

我运行了页面,然后刷新了它。该页面第一次成功执行。刷新时出现此错误。

Error Executing Database Query.  
** ERROR ** (7501) Name defined by CREATE TEMPORARY TABLE already exists.  

这就是我使用唯一表名的原因。我不缓存查询。具有讽刺意味的是,我使用临时表最常见的动机是因为在某些情况下它们比使用永久表运行得更快。

【讨论】:

  • 红砖不支持真正的临时表吗? (我没用过)
  • 这里解释了 Redbrick 临时表。 ibm.com/support/knowledgecenter/SSCRW7_6.3.0/…It is exclusive to the SQL session in which it is created 我对会话 wrt CF 的解释是,它是 CF 服务器和 redbrick 数据库之间的连接。我还假设一个打开的连接可以用于多个页面请求。
  • 我也考虑过使用唯一的表名。但问题就在这里。出于性能目的,我将整个查询缓存 30 分钟。如果每个函数调用的名称都是唯一的,那么查询也将是唯一的,因此这样的缓存将不起作用。我想我可以做一个cachePut 并这样做,但添加cachedWithin 效果更好,因为查询中有其他参数可以更改,cachedwithin 考虑到了这一点。,
  • 丹 - 谢谢。这听起来类似于 SQL Server 中的(非全局)临时表处理。至于连接,它们可以被多个请求重用如果 使用连接池。否则,每个请求都应该创建一个单独的连接或数据库“会话”。尽管我从未见过它记录在案,但 AFAIK 单个请求通常会为整个请求维护相同的连接或“会话”。换句话说,如果您请求一个运行五 (5) 个查询的页面,CF 应该为所有五个查询使用相同的连接,而不是为每个查询创建单独的连接。
  • (编辑)丹 - 我认为你误解了临时表和数据库会话应该如何工作。当保持连接启用时,您应该收到错误消息。当使用连接池时,现有的数据库连接被重用。这意味着多个请求可以共享同一个数据库会话。因此,临时表可能从一个请求到下一个请求都是可见的,这就是您在上面看到的。但是,当池禁用时,每个连接都会创建一个新的数据库会话,并且创建的任何临时表从一个请求到下一个请求都不可见。
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-07-26
  • 1970-01-01
  • 2019-09-12
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多