C# SqlConnection线程安全?

C# SqlConnection线程安全?,c#,multithreading,wcf,thread-safety,sqlconnection,C#,Multithreading,Wcf,Thread Safety,Sqlconnection,我有一个Log类,它将日志放在Windows日志和SQL表中。为了优化我的代码,我只想使用一个SqlConnection 在MSDN中,它表示:此类型的任何公共静态(在Visual Basic中共享)成员都是线程安全的。任何实例成员都不能保证线程安全 我的问题是: private static readonly SqlConnection conn = new SqlConnection(ConfigParameters.Instance.UIDConnection); 它是线程安全的吗?如果

我有一个
Log
类,它将日志放在Windows日志和SQL表中。为了优化我的代码,我只想使用一个
SqlConnection

在MSDN中,它表示:此类型的任何
公共静态
(在Visual Basic中共享)成员都是线程安全的。任何实例成员都不能保证线程安全

我的问题是:

private static readonly SqlConnection conn = new SqlConnection(ConfigParameters.Instance.UIDConnection);
它是线程安全的吗?如果是,当使用
Open()
Close()

如果没有,如何正确使用
SqlConnection

这是我的全班代码:

private static readonly SqlConnection conn = new SqlConnection(ConfigParameters.Instance.UIDConnection);

public static long WriteLog(string sSource, string sMessage, int iErrorCode, EventLogEntryType xErrorType)
{
    // Windows Logs
    if (ConfigParameters.Instance.WindowsLog)
        EventLog.WriteEntry(sSource, sMessage, xErrorType, iErrorCode);

    // SQL Logs
    // TODO

    return 0;
}

这不是共享SqlConnection的常见方式,只应在特殊情况下使用

首先,资源池是一种常见的模式,用于在使用套接字、网络流、web服务时提高性能

但特别是对于SqlConnection,您不必担心这一点,因为框架已经为您完成了这项工作,这要感谢

每当用户在连接上调用Open时,池处理程序都会查找 池中的可用连接。如果池连接可用, 它将其返回给调用方,而不是打开新连接。什么时候 应用程序在连接上调用Close,池程序返回它 指向活动连接的池集,而不是关闭它。一旦 连接返回到池中,即可在上重用 下一个公开电话

可以考虑SQL连接作为实际连接的包装器。不要认为实例化一个新的SqlConnection是昂贵的:事实并非如此,许多流量大的网站都是用它构建的

默认策略(至少对于sql server)是它将自动工作。您只需注意关闭连接(使用using块)。还有许多用于管理池的设置

您的代码还包含不正确的错误管理:如果连接中止(DBA、网络故障等),您将在记录时引发异常。。。不理想

因此,我认为在您的情况下,共享sql连接并不合适。使用异步日志库将获得更高的性能

在你确定这是一个真正的问题之前,不要把注意力集中在这个问题上

我们应该忘记小效率,比如说97%的时间: 过早优化是万恶之源,Donald Knuth


这不是共享SqlConnection的常见方式,只应在特殊情况下使用

首先,资源池是一种常见的模式,用于在使用套接字、网络流、web服务时提高性能

但特别是对于SqlConnection,您不必担心这一点,因为框架已经为您完成了这项工作,这要感谢

每当用户在连接上调用Open时,池处理程序都会查找 池中的可用连接。如果池连接可用, 它将其返回给调用方,而不是打开新连接。什么时候 应用程序在连接上调用Close,池程序返回它 指向活动连接的池集,而不是关闭它。一旦 连接返回到池中,即可在上重用 下一个公开电话

可以考虑SQL连接作为实际连接的包装器。不要认为实例化一个新的SqlConnection是昂贵的:事实并非如此,许多流量大的网站都是用它构建的

默认策略(至少对于sql server)是它将自动工作。您只需注意关闭连接(使用using块)。还有许多用于管理池的设置

您的代码还包含不正确的错误管理:如果连接中止(DBA、网络故障等),您将在记录时引发异常。。。不理想

因此,我认为在您的情况下,共享sql连接并不合适。使用异步日志库将获得更高的性能

在你确定这是一个真正的问题之前,不要把注意力集中在这个问题上

我们应该忘记小效率,比如说97%的时间: 过早优化是万恶之源,Donald Knuth


我发现:这是一个解决方案吗?为什么只想使用一个连接?这将增加您的开销,以防止线程问题。ADO.NET已经有内置的连接池,您可以通过使用语句将给定连接包装在
中,从而最大限度地减少使用该连接的时间。此外,这与WCF无关,因此您可以删除该标记。我之所以使用WCF,是因为我的Web服务需要连接到SQL。但你是对的。我可以将sqlConnection放在对象的实例中。但恐怕nb_线程*sqlconnection会占用大量内存。另一方面,如果我只使用静态sqlconnection,那么事务可能会更长。您认为将SqlConnection放在静态方法中更好吗?我发现:这是一个解决方案吗?为什么您只想使用一个连接?这将增加您的开销,以防止线程问题。ADO.NET已经有内置的连接池,您可以通过使用
语句将给定连接包装在
中,从而最大限度地减少使用该连接的时间。此外,这与WCF无关,因此您可以删除该标记。我之所以使用WCF,是因为我的Web服务需要连接到SQL。但你是对的。我可以将sqlConnection放在对象的实例中。但恐怕nb_线程*sqlconnection会占用大量内存。另一方面,如果我只使用静态sqlconnection,那么事务可能会更长。你认为把SqlConnection放在静态方法中更好吗?我把SqlConnection放在方法:)我把SqlConnection放在方法:)