28,390
社区成员
发帖
与我相关
我的任务
分享B/S业务程序中由于“并行”引起的问题的解决方法（高分）
在B/S结构中作业务处理程序，由于许多人同时进行操作属于相同或不同的程序，可能出现如下的情况：
A在进行产品设计修改，该产品设计修改可能引起物料清单的变化进行进行采购计划的调整（可能是数据减少，如删除某中产品结构的数据的时候），而在产生采购计划数据减少的操作前，B在对采购计划执行采购任务的分配，把不同的采购计划条目分给采购员，当数据减少的操作完成后，B还在进行采购计划的分配，而这些在分配的数据中可能已经不存在，这个时候对这些数据进行处理就会引起问题；比如采购计划分配的操作是把采购计划复制到采购任务中，那么就会出现采购任务里面有的东西在采购计划中不存在的情况，因为在进行复制前，采购计划已经不存在，而在客户端是存在的。
在ASP里面如何来解决这种问题？
１：用“锁”来解决，让分配采购计划到采购任务的工作和修改采购计划的工作串行工作，这样可以从原理上解决事情，但存在锁就存在解锁的问题，当进入页面加锁后，客户端出现异常情况，如自己关机怎么办，如何解锁？
２：在采购计划分配的执行的时候，执行采购计划数据的验证，并在验证和执行的时候采用事务来进行处理，这样又存在这种情况：B辛苦的执行采购计划分配，但执行的时候才发现数据已经更改了，工作白做
３：定时刷新的方法，通过一个隐藏域不断的更新数据，依旧不是一个很好的办法，轮询始终存在着时间间隔里面可能出现问题的危机。
请问各位，有好的解决思路和方法吗？
A在进行产品设计修改，该产品设计修改可能引起物料清单的变化进行进行采购计划的调整（可能是数据减少，如删除某中产品结构的数据的时候），而在产生采购计划数据减少的操作前，B在对采购计划执行采购任务的分配，把不同的采购计划条目分给采购员，当数据减少的操作完成后，B还在进行采购计划的分配，而这些在分配的数据中可能已经不存在，这个时候对这些数据进行处理就会引起问题；比如采购计划分配的操作是把采购计划复制到采购任务中，那么就会出现采购任务里面有的东西在采购计划中不存在的情况，因为在进行复制前，采购计划已经不存在，而在客户端是存在的。
在ASP里面如何来解决这种问题？
１：用“锁”来解决，让分配采购计划到采购任务的工作和修改采购计划的工作串行工作，这样可以从原理上解决事情，但存在锁就存在解锁的问题，当进入页面加锁后，客户端出现异常情况，如自己关机怎么办，如何解锁？
２：在采购计划分配的执行的时候，执行采购计划数据的验证，并在验证和执行的时候采用事务来进行处理，这样又存在这种情况：B辛苦的执行采购计划分配，但执行的时候才发现数据已经更改了，工作白做
３：定时刷新的方法，通过一个隐藏域不断的更新数据，依旧不是一个很好的办法，轮询始终存在着时间间隔里面可能出现问题的危机。
请问各位，有好的解决思路和方法吗？
...全文
请发表友善的回复…
发表回复
sharesunning 2004-05-11
- 打赏
- 举报
baby21st(流浪的脚) 说的没错,这里面的确存在一个权衡的问题,其实分布式的业务系统都存在这样的情况,不管是否是B/S结构的,有好的方法么?能否通过消息的方式来保证数据的及时性,再通过提交数据的时候来验证数据是否改变保证数据的准确性?
baby21st 2004-05-11
- 打赏
- 举报
楼主的问题跟“锁”关系好像不大
保证数据及时性可能才是最重要的
然后B/S模式受IE限制
可能楼主还是从定时刷新的角度来解决这个问题
保证数据及时性可能才是最重要的
然后B/S模式受IE限制
可能楼主还是从定时刷新的角度来解决这个问题
sharesunning 2004-05-11
- 打赏
- 举报
写完了发现写错了几个字，怕大家误解我的意思，从下如下：
我的问题可能大家理解的不太一样，用锁，一个广义上来讲的锁，从原理上来说当然不存在问题，主要的问题在于，这个过程是脱机的，这个过程可能会花不少的时间，比如采购主管分解采购计划给采购人员，执行下面的过程：
１：采购主管通过ado读取采购计划，采购计划下载到浏览器后，此时的操作和服务器与ado不再有任何关系;
２：依据实际情况，采购主管人工对采购计划进行选取分配，选择采购员和他所对应该处理的任务，这些操作和服务器，ado也没有任何关系，因为他还没有提交任何数据，而操作的性质可能是一个人的思考工作的过程，可能花上一个小时或者说五分钟时间;
３：提交分配的结果，通过ado把分配的结果写入数据库，这个过程和ado与数据库发生关系。
问题出在步骤二进行的时候，有其它的人或者说其它程序修改了共用的采购计划，而采购主管并不知道，使得采购主管此时看到的采购计划和实际保存在数据库里面的采购计划存在了差异，可能一些计划已经不存在；当然分配的任务也就会有错误！
这种问题如何解决？
整个问题的发生不是在一个ado记录集打开到关闭的过程中发生的，而是在数据下载到了IE后发生的
同样，从联机脱机的关系和时间的要求上来看，锁好像也不合适来解决这个问题，请指正！
我的问题可能大家理解的不太一样，用锁，一个广义上来讲的锁，从原理上来说当然不存在问题，主要的问题在于，这个过程是脱机的，这个过程可能会花不少的时间，比如采购主管分解采购计划给采购人员，执行下面的过程：
１：采购主管通过ado读取采购计划，采购计划下载到浏览器后，此时的操作和服务器与ado不再有任何关系;
２：依据实际情况，采购主管人工对采购计划进行选取分配，选择采购员和他所对应该处理的任务，这些操作和服务器，ado也没有任何关系，因为他还没有提交任何数据，而操作的性质可能是一个人的思考工作的过程，可能花上一个小时或者说五分钟时间;
３：提交分配的结果，通过ado把分配的结果写入数据库，这个过程和ado与数据库发生关系。
问题出在步骤二进行的时候，有其它的人或者说其它程序修改了共用的采购计划，而采购主管并不知道，使得采购主管此时看到的采购计划和实际保存在数据库里面的采购计划存在了差异，可能一些计划已经不存在；当然分配的任务也就会有错误！
这种问题如何解决？
整个问题的发生不是在一个ado记录集打开到关闭的过程中发生的，而是在数据下载到了IE后发生的
同样，从联机脱机的关系和时间的要求上来看，锁好像也不合适来解决这个问题，请指正！
sharesunning 2004-05-11
- 打赏
- 举报
我的问题可能大家理解的不太一样，用锁，从原理上来说当然不存在问题，主要的问题在于，比如我分解采购计划给我的采购人员，执行下面的过程：
１：采购主管通过ado读取采购计划，采购计划下载到浏览器后，此时和服务器与ado不再有任何关系;
２：依据实际情况，人工对采购计划进行选取分配，选择采购员和他所对应该处理的任务，这个和服务器，ado也没有任何关系，可能是一个人的思考过程，可能话上一个小时或者说五分钟;
３：提交分配的结果，通过ado把分配的结果写入数据库
问题出在步骤二进行的时候，有人或者说程序修改了采购计划，使得此时采购主管看到的采购计划和实际保存在数据采购计划存在了差异，可能一些数据已经不存在；
这种问题如何解决？
整个问题的发生不是在一个ado记录集打开的过程中发生的，而是在数据下载到了IE后发生的
同样，锁也是很合适宜，感觉啊，请指正！
１：采购主管通过ado读取采购计划，采购计划下载到浏览器后，此时和服务器与ado不再有任何关系;
２：依据实际情况，人工对采购计划进行选取分配，选择采购员和他所对应该处理的任务，这个和服务器，ado也没有任何关系，可能是一个人的思考过程，可能话上一个小时或者说五分钟;
３：提交分配的结果，通过ado把分配的结果写入数据库
问题出在步骤二进行的时候，有人或者说程序修改了采购计划，使得此时采购主管看到的采购计划和实际保存在数据采购计划存在了差异，可能一些数据已经不存在；
这种问题如何解决？
整个问题的发生不是在一个ado记录集打开的过程中发生的，而是在数据下载到了IE后发生的
同样，锁也是很合适宜，感觉啊，请指正！
qunluo 2004-04-29
- 打赏
- 举报
记号！
ycted 2004-04-28
- 打赏
- 举报
看了，来了3年多的回帖，虽然从字面上已经理解，但是实际操作起来还是一头雾水。
关注！
关注！
qiangtian 2004-04-28
- 打赏
- 举报
没看明白，关注一下
chendongqiang 2004-04-28
- 打赏
- 举报
以前考虑过这种问题，后来不了了之了，关注！
liuyu202 2004-04-28
- 打赏
- 举报
关注！
blues-star 2004-04-28
- 打赏
- 举报
锁定提示
可以使用 SELECT、INSERT、UPDATE 和 DELETE 语句指定表级锁定提示的范围，以引导 Microsoft® SQL Server™ 2000 使用所需的锁类型。当需要对对象所获得锁类型进行更精细控制时，可以使用表级锁定提示。这些锁定提示取代了会话的当前事务隔离级别。
说明 SQL Server 查询优化器自动作出正确的决定。建议仅在必要时才使用表级锁定提示更改默认的锁定行为。禁止锁定级别反过来会影响并发。
锁定提示 描述
HOLDLOCK 将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK 等同于 SERIALIZABLE。
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
PAGLOCK 在通常使用单个表锁的地方采用页锁。
READCOMMITTED 用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。
READPAST 跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。READPAST 锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于 SELECT 语句。
READUNCOMMITTED 等同于 NOLOCK。
REPEATABLEREAD 用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。
ROWLOCK 使用行级锁，而不使用粒度更粗的页级锁和表级锁。
SERIALIZABLE 用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。
TABLOCK 使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL Server 一直持有该锁。但是，如果同时指定 HOLDLOCK，那么在事务结束之前，锁将被一直持有。
TABLOCKX 使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。
XLOCK 使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用 PAGLOCK 或 TABLOCK 指定该锁，这种情况下排它锁适用于适当级别的粒度。
例如，如果将事务隔离级别设置为 SERIALIZABLE，并且在 SELECT 语句中使用表级锁定提示 NOLOCK，则键范围锁通常用于维护不采用可串行事务。
USE pubs
GO
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
SELECT au_lname FROM authors WITH (NOLOCK)
GO
生成的锁是：
EXEC sp_lock
GO
spid dbid ObjId IndId Type Resource Mode Status
1 1 0 0 DB S GRANT
6 1 0 0 DB S GRANT
7 1 0 0 DB S GRANT
8 4 0 0 DB S GRANT
8 4 0 0 DB S GRANT
8 4 117575457 0 TAB Sch-S GRANT
9 4 0 0 DB S GRANT
9 1 21575115 0 TAB IS GRANT
SELECT object_name(117575457)
GO
-----------------------------
authors
引用 authors 唯一采用的锁是架构稳定性 (Sch-S) 锁。在这种情况下不能保证可串行性。
请参见
DELETE
INSERT
SELECT
SET TRANSACTION ISOLATION LEVEL
UPDATE
可以使用 SELECT、INSERT、UPDATE 和 DELETE 语句指定表级锁定提示的范围，以引导 Microsoft® SQL Server™ 2000 使用所需的锁类型。当需要对对象所获得锁类型进行更精细控制时，可以使用表级锁定提示。这些锁定提示取代了会话的当前事务隔离级别。
说明 SQL Server 查询优化器自动作出正确的决定。建议仅在必要时才使用表级锁定提示更改默认的锁定行为。禁止锁定级别反过来会影响并发。
锁定提示 描述
HOLDLOCK 将共享锁保留到事务完成，而不是在相应的表、行或数据页不再需要时就立即释放锁。HOLDLOCK 等同于 SERIALIZABLE。
NOLOCK 不要发出共享锁，并且不要提供排它锁。当此选项生效时，可能会读取未提交的事务或一组在读取中间回滚的页面。有可能发生脏读。仅应用于 SELECT 语句。
PAGLOCK 在通常使用单个表锁的地方采用页锁。
READCOMMITTED 用与运行在提交读隔离级别的事务相同的锁语义执行扫描。默认情况下，SQL Server 2000 在此隔离级别上操作。
READPAST 跳过锁定行。此选项导致事务跳过由其它事务锁定的行（这些行平常会显示在结果集内），而不是阻塞该事务，使其等待其它事务释放在这些行上的锁。READPAST 锁提示仅适用于运行在提交读隔离级别的事务，并且只在行级锁之后读取。仅适用于 SELECT 语句。
READUNCOMMITTED 等同于 NOLOCK。
REPEATABLEREAD 用与运行在可重复读隔离级别的事务相同的锁语义执行扫描。
ROWLOCK 使用行级锁，而不使用粒度更粗的页级锁和表级锁。
SERIALIZABLE 用与运行在可串行读隔离级别的事务相同的锁语义执行扫描。等同于 HOLDLOCK。
TABLOCK 使用表锁代替粒度更细的行级锁或页级锁。在语句结束前，SQL Server 一直持有该锁。但是，如果同时指定 HOLDLOCK，那么在事务结束之前，锁将被一直持有。
TABLOCKX 使用表的排它锁。该锁可以防止其它事务读取或更新表，并在语句或事务结束前一直持有。
UPDLOCK 读取表时使用更新锁，而不使用共享锁，并将锁一直保留到语句或事务的结束。UPDLOCK 的优点是允许您读取数据（不阻塞其它事务）并在以后更新数据，同时确保自从上次读取数据后数据没有被更改。
XLOCK 使用排它锁并一直保持到由语句处理的所有数据上的事务结束时。可以使用 PAGLOCK 或 TABLOCK 指定该锁，这种情况下排它锁适用于适当级别的粒度。
例如，如果将事务隔离级别设置为 SERIALIZABLE，并且在 SELECT 语句中使用表级锁定提示 NOLOCK，则键范围锁通常用于维护不采用可串行事务。
USE pubs
GO
SET TRANSACTION ISOLATION LEVEL SERIALIZABLE
GO
BEGIN TRANSACTION
SELECT au_lname FROM authors WITH (NOLOCK)
GO
生成的锁是：
EXEC sp_lock
GO
spid dbid ObjId IndId Type Resource Mode Status
1 1 0 0 DB S GRANT
6 1 0 0 DB S GRANT
7 1 0 0 DB S GRANT
8 4 0 0 DB S GRANT
8 4 0 0 DB S GRANT
8 4 117575457 0 TAB Sch-S GRANT
9 4 0 0 DB S GRANT
9 1 21575115 0 TAB IS GRANT
SELECT object_name(117575457)
GO
-----------------------------
authors
引用 authors 唯一采用的锁是架构稳定性 (Sch-S) 锁。在这种情况下不能保证可串行性。
请参见
DELETE
INSERT
SELECT
SET TRANSACTION ISOLATION LEVEL
UPDATE
blues-star 2004-04-28
- 打赏
- 举报
反正我看联机丛书是迷迷糊糊地,建议你去数据库版找牛人问问
cjf1009 2004-04-28
- 打赏
- 举报
mark
blues-star 2004-04-28
- 打赏
- 举报
摘自SQL SERVER联机丛书
锁定构架
锁是由软件使用的对象，用于表明用户与资源有某种相关性。软件不允许其它用户在资源上执行将对拥有锁的用户的相关性产生负面影响的操作。锁由系统软件在内部管理，并基于用户所执行的操作被获取和释放。
Microsoft® SQL Server™ 2000 使用锁在多个同时在数据库内执行修改的用户间实现悲观并发控制。默认情况下，SQL Server 基于每个连接管理事务和锁。例如，如果应用程序打开两个 SQL Server 连接，由一个连接获取的锁不能与另一个连接共享。两个连接都不能获取将与另一个连接所控制的锁冲突的锁。只有绑定连接不受该规则的影响。有关更多信息，请参见使用绑定连接。
SQL Server 锁在数据库内的不同粒度级别上应用。可以为行、页、键、键范围、索引、表或数据库获取锁。SQL Server 动态确定每个 Transact-SQL 语句的锁的适当的放置级别。获取锁的级别可能因同一查询所引用的不同对象而异；例如一个表可能很小，因此应用表锁，而另一个大表则可以应用行锁。应用表锁的级别不必由用户指定，而且不需要管理员配置。SQL Server 实例确保在一个粒度级上授予的锁不妨碍在另一个级别上授予的锁。例如，如果 UserA 试图在行上获取共享锁，SQL Server 实例也会试图在页和表上获取意向共享锁。如果 UserB 在页或表级上有一个排它锁，UserA 将被阻塞，直到 UserB 控制的锁被释放才能获取锁。
有几种锁模式：共享锁、更新锁、排它锁、意向锁和架构锁。锁模式表明连接与锁定对象所具有的相关性等级。SQL Server 控制锁模式的交互方式。例如，如果其它连接对资源具有共享锁，则不能获得排它锁。
锁保持的时间长度为保护所请求级别上的资源所需的时间长度。
用于保护读取操作的共享锁的保持时间取决于事务隔离级别。采用 READ COMMITTED 的默认事务隔离级别时，只在读取页的期间内控制共享锁。在扫描中，直到在扫描内的下一页上获取锁时才释放锁。如果指定 HOLDLOCK 提示或者将事务隔离级别设置为 REPEATABLE READ 或 SERIALIZABLE，则直到事务结束才释放锁。
根据为游标设置的并发选项，游标可以获取共享模式的滚动锁以保护提取。当需要滚动锁时，直到下一次提取或关闭游标（以先发生者为准）时才释放滚动锁。但是，如果指定 HOLDLOCK，则直到事务结束才释放滚动锁。
用于保护更新的排它锁将直到事务结束才释放。
如果一个连接试图获取一个锁，而该锁与另一个连接所控制的锁冲突，则试图获取锁的连接将一直阻塞到：
将冲突锁释放而且连接获取了所请求的锁。
连接的超时间隔已到期。默认情况下没有超时间隔，但是一些应用程序设置超时间隔以防止无限期等待。
如果几个连接因在某个单独的资源上等待冲突的锁而被阻塞，那么在前面的连接释放锁时将按先来先服务的方式授予锁。
SQL Server 有一个算法可以检测死锁，即两个连接互相阻塞的情况。如果 SQL Server 实例检测到死锁，将终止一个事务，以使另一个事务继续。有关更多信息，请参见死锁。
SQL Server 可以动态升级或降级锁粒度或锁类型。例如，如果更新获取大量行锁而阻塞了表的大部分，将行锁升级到表锁。如果获取了表锁，将释放行锁。SQL Server 2000 很少需要升级锁；查询优化器在编译执行计划时通常选择正确的锁粒度。有关更多信息，请参见锁升级和动态锁定。
锁定构架
锁是由软件使用的对象，用于表明用户与资源有某种相关性。软件不允许其它用户在资源上执行将对拥有锁的用户的相关性产生负面影响的操作。锁由系统软件在内部管理，并基于用户所执行的操作被获取和释放。
Microsoft® SQL Server™ 2000 使用锁在多个同时在数据库内执行修改的用户间实现悲观并发控制。默认情况下，SQL Server 基于每个连接管理事务和锁。例如，如果应用程序打开两个 SQL Server 连接，由一个连接获取的锁不能与另一个连接共享。两个连接都不能获取将与另一个连接所控制的锁冲突的锁。只有绑定连接不受该规则的影响。有关更多信息，请参见使用绑定连接。
SQL Server 锁在数据库内的不同粒度级别上应用。可以为行、页、键、键范围、索引、表或数据库获取锁。SQL Server 动态确定每个 Transact-SQL 语句的锁的适当的放置级别。获取锁的级别可能因同一查询所引用的不同对象而异；例如一个表可能很小，因此应用表锁，而另一个大表则可以应用行锁。应用表锁的级别不必由用户指定，而且不需要管理员配置。SQL Server 实例确保在一个粒度级上授予的锁不妨碍在另一个级别上授予的锁。例如，如果 UserA 试图在行上获取共享锁，SQL Server 实例也会试图在页和表上获取意向共享锁。如果 UserB 在页或表级上有一个排它锁，UserA 将被阻塞，直到 UserB 控制的锁被释放才能获取锁。
有几种锁模式：共享锁、更新锁、排它锁、意向锁和架构锁。锁模式表明连接与锁定对象所具有的相关性等级。SQL Server 控制锁模式的交互方式。例如，如果其它连接对资源具有共享锁，则不能获得排它锁。
锁保持的时间长度为保护所请求级别上的资源所需的时间长度。
用于保护读取操作的共享锁的保持时间取决于事务隔离级别。采用 READ COMMITTED 的默认事务隔离级别时，只在读取页的期间内控制共享锁。在扫描中，直到在扫描内的下一页上获取锁时才释放锁。如果指定 HOLDLOCK 提示或者将事务隔离级别设置为 REPEATABLE READ 或 SERIALIZABLE，则直到事务结束才释放锁。
根据为游标设置的并发选项，游标可以获取共享模式的滚动锁以保护提取。当需要滚动锁时，直到下一次提取或关闭游标（以先发生者为准）时才释放滚动锁。但是，如果指定 HOLDLOCK，则直到事务结束才释放滚动锁。
用于保护更新的排它锁将直到事务结束才释放。
如果一个连接试图获取一个锁，而该锁与另一个连接所控制的锁冲突，则试图获取锁的连接将一直阻塞到：
将冲突锁释放而且连接获取了所请求的锁。
连接的超时间隔已到期。默认情况下没有超时间隔，但是一些应用程序设置超时间隔以防止无限期等待。
如果几个连接因在某个单独的资源上等待冲突的锁而被阻塞，那么在前面的连接释放锁时将按先来先服务的方式授予锁。
SQL Server 有一个算法可以检测死锁，即两个连接互相阻塞的情况。如果 SQL Server 实例检测到死锁，将终止一个事务，以使另一个事务继续。有关更多信息，请参见死锁。
SQL Server 可以动态升级或降级锁粒度或锁类型。例如，如果更新获取大量行锁而阻塞了表的大部分，将行锁升级到表锁。如果获取了表锁，将释放行锁。SQL Server 2000 很少需要升级锁；查询优化器在编译执行计划时通常选择正确的锁粒度。有关更多信息，请参见锁升级和动态锁定。
lawdoor 2004-04-28
- 打赏
- 举报
建议好好研究一下ADO再动手做这个事情！
blues-star 2004-04-28
- 打赏
- 举报
SQL 联机丛书中也有,这个里面的可能是你想要的.
lawdoor 2004-04-28
- 打赏
- 举报
有没有考虑过用权限划分来解决这个问题！不同人有不同的权限，B辛苦的执行采购计划分配只能有与B同等权限的人才可以进行修改，限制权限人数！
blues-star 2004-04-28
- 打赏
- 举报
仔细看看ADO的SDK,recordset.open的时候有锁类型的选择
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
recordset.Open Source, ActiveConnection, CursorType, LockType, Options
