c# - 在 C# SQLCLR 中更改静态只读变量是否安全？

Question

我在 C# 6.0 .NET 3.5 CLR 程序集中编写了一些安全级别为 external_access 的代码。

精简代码:

 public static readonly DataTable warnings_table = init_warnings_table();

 public static void set_warning(string msg)
 {
        var row = warnings_table.NewRow();
        row[1] = DateTime.Now;
        row[2] = msg;
                ...
        warnings_table.Rows.Add(row);
 }
 [Microsoft.SqlServer.Server.SqlProcedure]
 public static SqlInt32 wrapper_func(SqlInt32 param)
 { 
   return big_func(Param.Value);
 }

 int big_func(int param)
 { 
   SqlBulkCopy bulkcopy;
   ....
   set_warning("Message");
   ....
   write_warnings(bulkcopy); 
   warnings_table.Clear();
 }

如果 wrapper_func 将同时从 2 个或多个不同的连接/ session 调用，warnings_table 会发生什么情况？静态字段warnings_table有写操作。所以，我想，但我不确定，这会导致此处出现数据竞争条件。

换句话说:

1. 对于每个 sql 连接/sql 查询/事务，SQLCLR 中的static read-only 变量是否是唯一的，或者它们是否在不同的 SQLCLR 过程调用之间共享数据？

2. 是否可以拥有无​​痛的全局状态，不受其他 SQLCLR 过程调用的影响？

Answer 1

Are static read-only variables in SQLCLR unique for every sql connection/sql query/transactions or do they share data between different SQLCLR procedures calls?

驻留在 SQL Server 内部的程序集(即 SQLCLR)被加载到单个应用程序域中，该应用程序域在所有 session 之间共享。可以有多个应用程序域，因为它们特定于每个数据库和所有者(即授权)组合。但是任何一个特定的 SQLCLR 对象都只会驻留在一个特定的程序集中，因此对它的所有调用都共享该单个实例。这就是为什么所有 SQLCLR 方法都需要是 static 的原因，因为它们不是针对每个 session 的。所以是的，静态成员/类变量是共享的，这就是为什么它们需要声明为 readonly，否则程序集需要有 PERMISSION_SET UNSAFE 如果静态类变量未标记为 readonly。

Is it possible to have painless global state, safe from other SQLCLR procedures calls?

不，至少不是以任何简单的内置方式。作为 Collection 的静态类变量可以被认为是在 tempdb 中创建的真实表(不同于全局临时表 -- ##Table)。一旦创建了变量，它将保留并且不会在创建它的“ session ”结束后消失，但所有 session 都可以访问它。因此，如果您需要对每个 session 进行分离，那么您需要将静态集合的一个属性作为区分器——用来区分每个 session 的东西。您可以获得当前的 session_id/@@SPID 并使用它，只要您在每个进程开始时清除所有具有相同 session_id 的条目，因为 session_id 值被 SQL Server 重新使用。但是没有办法清除未重复使用的 session_id 值的条目，除非您将其作为流程结束时的最后一步(如果流程遇到异常则可能不会调用该步骤)。所以，并非不可能，但需要一些工作和大量测试 :-)。

还应了解，这并非特定于 SQLCLR 存储过程，而是影响在特定应用程序域中运行的所有方法和对象。这意味着，静态类变量与可以访问该类的所有代码共享，这些代码可以是 SQLCLR 触发器、函数，也可能是用户定义的聚合和用户定义的类型。

请注意，关于静态变量和 SQL Server 如何管理内存，您需要注意的一个细微差别是:

有时，如果 SQL Server 的物理内存不足，它可能会决定卸载一个或多个应用程序域。您可以通过搜索“内存压力”在 SQL Server 错误日志中看到此行为，因为会有以下形式的条目:

AppDomain X ({database_name}.{owner_name}[runtime].Y) is marked for unload due to memory pressure.

卸载应用程序域将清除静态变量。当它在下次调用 SQLCLR 对象时重新加载时，将再次创建静态变量。

所以，如果静态变量被用于维护“正确”操作所必需的调用之间的状态，那么您需要找到另一种方法，因为无法保证在调用之间存在该数据.

如果您需要 per-Session 全局状态，那么您需要通过使用 Context Connection = true; 执行 T-SQL 语句来使用 SQL Server 内置机制连接字符串。您可以使用:

• 本地临时表
• SET CONTEXT_INFO/CONTEXT_INFO()
• (截至 SQL Server 2016)sp_set_session_context/SESSION_CONTEXT

---

有关一般使用 SQLCLR 的更多信息，请参阅我在 SQL Server Central 上就此主题撰写的系列文章(需要免费注册):

Stairway to SQLCLR