求助，怎样锁定Sql中的某一条记录

[宜兴SEO]

如题，在做一个Web系统，在同一个时间，同一条记录是只可以一个人在修改，怎样才能做到这一点，Sql中可以锁定记录吗？

[q107770540]

悲观式并发

[宜兴SEO]

[Quote=引用 1 楼 q107770540 的回复:]
悲观式并发
[/Quote]怎么说？老大

[MOTA]

在看论文的过程中突然出现了一个自己很陌生的术语——乐观并发控制，在网上展开了搜查，看了之后终于明白了其中的含义。乐观并发事务和悲观并发事务的区别如下：
悲观并发控制
一个锁定系统，可以阻止用户以影响其他用户的方式修改数据。如果用户执行的操作导致应用了某个锁，只有这个锁的所有者释放该锁，其他用户才能执行与该锁冲突的操作。这种方法之所以称为悲观并发控制，是因为它主要用于数据争用激烈的环境中，以及发生并发冲突时用锁保护数据的成本低于回滚事务的成本的环境中。
乐观并发控制
在乐观并发控制中，用户读取数据时不锁定数据。当一个用户更新数据时，系统将进行检查，查看该用户读取数据后其他用户是否又更改了该数据。如果其他用户更新了数据，将产生一个错误。一般情况下，收到错误信息的用户将回滚事务并重新开始。这种方法之所以称为乐观并发控制，是由于它主要在以下环境中使用：数据争用不大且偶尔回滚事务的成本低于读取数据时锁定数据的成本。
具体的区别与实例说明如下：

悲观并发控制：假设A和B需要在SCC（Source Code Control）上修改同一个文件，那么在A锁定这个文件并修改的过程中，B无法修改这个文件，他只能等待A解锁文件后，他才能修改。由此可见，悲观并发控制是强调控制在前，确保整个过程不会出现文件版本的冲突。这样做会使得系统效率损耗在加锁机制上，尤其是加锁机制需要用到低速的外部存储（比如FileLocking）时，然而这样做就降低了事务的并发性，尤其是事务之间本来就不存在冲突的情况下。例如在A修改数据的时候，B只能等待。

由此可见，悲观并发控制通过使用显式的加锁机制或者时间戳，对每一个事务进行增量同步校验。如果加锁机制的成本较高的话，悲观并发控制就会出现一些弊端。首先就是效率问题，尤其是使用低效率的外部存储系统实现加锁机制时，这样的问题会更加突出。其次，在不会出现冲突的事务处理（例如只读型事务）中，使用加锁机制就显得没有必要了，这样做只能增加系统负载。再次，这种方式降低了系统的并发性。

乐观并发控制：同样假设A和B需要在SCC上修改同一个文件，他们都将这个文件获取到自己的机器上，A修改完以后，就把文件上传到SCC上了，此时B也修改完了，当他也打算将文件上传时，系统会告知B，已经有人上传了，并出现一个错误。剩下的问题只能由B手动解决，例如B可以在SCC上将文件中更改的内容再次复制一遍。乐观并发控制使得系统效率损耗在事务的后期处理中，比如B必须手动的去修改他已经修改过的东西，然而这种控制方式在极少出现冲突的多事务处理中显得十分高效。

乐观并发控制将事务分为三个阶段：读取阶段、校验阶段以及写入阶段。在读取阶段，事务将数据写入本地缓冲（如上所述，A和B将文件都获取到自己的机器上），此时不会有任何校验操作；在校验阶段，系统会对所有的事务进行同步校验（比如在A或者B打算，但还没有，往SCC上写入更改后的文件时）；在写入阶段，数据将被最终提交。在完成读取阶段以后，系统会对每个事务分派一个时间戳。

悲观并发控制中一个常见的问题就是死锁。例如A在修改文件T1，B在修改文件T2，他们分别锁定了这两个文件，假设T1和T2内容相关，B在修改T2的时候发现他还需要修改T1，可是T1却被A锁定；与此同时，A在修改T1的时候也发现了他还需要修改T2，可是T2又被B锁定了，这样就出现了死锁。当然，在实际操作中，这种情况可以由A和B协商解决，但是在错综复杂的多事务处理环境中，死锁将使得问题变得非常复杂。

这个是那个哥们说的东西

我做貌似是直接加个列 用来控制是否允许被修改。

[peilianhai]

我理解应该是不止一个人都打开一修改页面，当更新时，做的验证

sql 可以设置一修改字段
人一，人二同时要修改
人一 修改完，同时 同步 修改时间字段

人二，更新时，判断，读取到的 修改时间，是否与数据库修改时间字段 相同，如果不同，提示有人更改过
相同，可以更新

[wuyq11]

修改表中标识，表示正在使用
锁机制，维持几秒

[宜兴SEO]

最头痛的是，如果加字段，或者把正在修改的ID存如缓存的话，那如果那人没修改玩，直接把浏览器关了，那就悲剧了~

[以专业开发人员为伍]

数据库事务会保持ACID特性，它可以避免并行的Update同一个记录。如果你没有在你的.net程序中显式地启用数据库事务，SQL Server也会自动为每一条sql语句启用一个事务。所以单纯技术上说，你不用担心什么“多个人Update”的问题。

但是从技术上不用担心，并不等于从业务逻辑上不用担心。会解决技术问题，不一定会解决业务问题。你所说的“在同一时间”我看不明白是什么概念？！假如你是说一个人修改了一个记录，然后坐在电脑前发呆，然后再按“确认键”，如果你说的是这一个长事务时间，那么数据库是不适合来做这类事务问题的，只有你的业务逻辑程序来保证。

[以专业开发人员为伍]

[Quote=引用 6 楼 qq66866111 的回复:]

最头痛的是，如果加字段，或者把正在修改的ID存如缓存的话，那如果那人没修改玩，直接把浏览器关了，那就悲剧了~
[/Quote]

数据库是个成熟的东西，不是来研究的东西。不是什么自己编写一个字段的问题。

嗯，找一本30年前的数据库技术教程，其中可能有至少六分之一的篇幅都是关于事务机制的实现的。

[以专业开发人员为伍]

数据库技术有几个核心的机制，比如：磁盘块存取（包括预取技术）以及将多条记录组织在磁盘块中、各种索引技术（起码要使用B+树）、事务、SQL编译和执行、分布式。

这是数据库技术最起码的功能，也是为什么选择数据库而不是xml文件之类的东西的本质特征。任何一本数据库技术的教科书都会包括这些内容，告诉你如何设计一个数据库系统。

[LingKen]

我晕，说了这么多话，楼主也解决不了问题的，不如给点代码

[wang329382414]

slect a1 from table1 with(UPLOCK )

[wang329382414]

slect a1 from table1 with(UPLOCK ) where

[kenriy]

事务机制的实现