Question

C#.net中多SQL对象关于锁的问题。

标准3层架构。 有一个SQL类专门用来连接数据库，这个类里的方法很多，有各种对数据库数据查询，更新删除等方法。其中有两个方法，一个是open（）方法，就是专门打开数据库连接的，另一个是close()方法，是关闭数据库连接的。。 但是我们都知道，经常对数据库打开和关闭连接对性能的影响是非常大的。所以我构思了以下的方法。
现在，我想做这样一个程序，就是首先实例化一个sql1，然后让这个sql1全程都保持打开连接状态，除非主程序关闭。然后sql1的作用就是用来查询用的，不进行更新和删除。所以在实例化sql1的时候我把他的锁设置为共享锁。
然后实例化一个sql2，他主要用来对数据库进行增删改操作的。。 平时并不对数据库进行连接，仅仅是需要操作的时候才打开数据库连接，操作完毕后关闭连接。
现在有两个问题，
第一是在sql1对数据库保持共享锁连接时，sql2还能否打开与数据库的链接。如果正常方法不能，有没有什么办法可以办到。
第二个是，我知道如果数据库中某一条记录锁的状态时共享锁时，当其他进程想对他进行更新操作，那么容易发生死锁。我以上说的方法是否也会产生死锁，要如何避免。
如果回答的好，我会追加50分。先谢谢各位大大。

Answer 1

从数据库系统的角度来看：分为独占锁（即排它锁），共享锁和更新锁
MS-SQL Server 使用以下资源锁模式。
锁模式 描述
共享 (S) 用于不更改或不更新数据的操作（只读操作），如 SELECT 语句。
更新 (U) 用于可更新的资源中。防止当多个会话在读取、锁定以及随后可能进行的资源更新时发生常见形式的死锁。
排它 (X) 用于数据修改操作，例如 INSERT、UPDATE 或 DELETE。确保不会同时同一资源进行多重更新。
意向锁 用于建立锁的层次结构。意向锁的类型为：意向共享 (IS)、意向排它 (IX) 以及与意向排它共享 (SIX)。
架构锁 在执行依赖于表架构的操作时使用。架构锁的类型为：架构修改 (Sch-M) 和架构稳定性 (Sch-S)。
大容量更新 (BU) 向表中大容量复制数据并指定了 TABLOCK 提示时使用。
◆共享锁
共享 (S) 锁允许并发事务读取 (SELECT) 一个资源。资源上存在共享 (S) 锁时，任何其它事务都不能修改数据。一旦已经读取数据，便立即释放资源上的共享 (S) 锁，除非将事务隔离级别设置为可重复读或更高级别，或者在事务生存周期内用锁定提示保留共享 (S) 锁。
◆更新锁
更新 (U) 锁可以防止通常形式的死锁。一般更新模式由一个事务组成，此事务读取记录，获取资源（页或行）的共享 (S) 锁，然后修改行，此操作要求锁转换为排它 (X) 锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它 (X) 锁。共享模式到排它锁的转换必须等待一段时间，因为一个事务的排它锁与其它事务的共享模式锁不兼容；发生锁等待。第二个事务试图获取排它 (X) 锁以进行更新。由于两个事务都要转换为排它 (X) 锁，并且每个事务都等待另一个事务释放共享模式锁，因此发生死锁。
若要避免这种潜在的死锁问题，请使用更新 (U) 锁。一次只有一个事务可以获得资源的更新 (U) 锁。如果事务修改资源，则更新 (U) 锁转换为排它 (X) 锁。否则，锁转换为共享锁。
◆排它锁
排它 (X) 锁可以防止并发事务对资源进行访问。其它事务不能读取或修改排它 (X) 锁锁定的数据。

Answer 2

分为独占锁（排他锁），从点的数据库系统共享锁和更新锁
MS-SQL Server使用以下资源锁模式。
锁模式是用来描述
共享（S）不更改或不更新数据的操作（只读操作），如SELECT语句。
可再生资源的更新（U）。防止死锁时常见的形式，多个会话在读取，锁定以及随后可能进行的资源更新。
排它（X）用于数据操作，例如INSERT，UPDATE或DELETE。多个更新程序，以确保在相同的时间在相同的资源。
意向锁用于建立锁的层次结构。意向锁的类型：意向共享（IS），意向排它（IX）以及与意向排它（SIX）共享。
架构锁执行依赖于表架构的操作。架构锁的类型为：架构（SCH-M）和架构稳定性（SCH-S）。
大容量更新（BU），将数据复制到指定的表容量TABLOCK提示。
◆共享锁
共享（S）锁允许并发事务读取（SELECT）一个资源。资源共享（S）锁时，任何其它事务都不能数据。一旦数据被读取后，立即释放资源共享（S）锁，除非将事务隔离级别设置为可重复读或更高级别的交易，或持续时间与锁定提示保留共享（S）锁。
◆更新锁
更新（U）锁可以防止通常形式的死锁。一般更新模式由一个事务，此事务读取记录，获取资源（页或行）的共享（S）锁，然后行，此操作要求锁转换为排它（X）锁。如果两个事务获得了资源上的共享模式锁，然后试图同时更新数据，则一个事务尝试将锁转换为排它（X）锁。共享模式到排他锁的转换必须等待一段时间，因为一个事务的排它锁共享模式锁不兼容的其他事务;发生锁等待。第二个事务试图获取排它（X）锁以进行更新。由于交易双方都转换为排它（X）锁，并且他们都在等待另一个事务释放共享模式锁，因此发生死锁。
为了避免这种潜在的死锁问题，更新（U）锁。只有一个事务可以获得资源的更新（U）锁。如果事务资源，则更新（U）锁转换为排它（X）锁。否则，锁被转换到一个共享锁。
◆排他锁
排它（X）锁可以防止并发事务访问资源。其它事务不能读取或排它（X）锁数据。

Answer 3

1、sql2是可以打开的
2、一般情况下，只要你的sql2不同时操作同一记录是不会发生死锁的，注意最好不要使用表锁，即不要将整个表锁住，而是使用行所将用到的几行数据锁住即可。
3、最主要看你的数据访问的并发程度，其实你使用一个sql1长时间打开数据库连接，如果客户端比较多一样会浪费数据库资源。
以上是个人见解。

Answer 4

多余.net自带连接池.一般来说不要自己实现.
SQL类不要open和close方法,
就在具体访问数据库的方法里.采用即用即断方式.

追问

我指的open方法其实是 connection.Open()。
按照常理来说每个方法结束时都应该connection.close（）一下以释放内存。
但是我想在主程序开始时打开，结束时才关闭，暂时不考虑内存的关系。那么这样连接一直处于open状态会不会对数据库照成加锁？

追答

这要看你执行sql语句的.我不能很肯定,但很有可能导致一直加锁,然后会触发数据库的解锁机制,导致回滚和异常,
所以说不要这样做.不要在一开始打开连接,在最后关闭,明白吗,
这样做没有好处.只会带来死锁的风险.