多用户同时处理同一条数据解决办法

本文介绍了一种通过增加LAST_UPDATE字段并结合触发器来解决多用户并发更新同一记录时产生的冲突问题的方法。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

在c/s或多层中,如果两个用户同时打开一条记录,修改后提交会产生更新冲突;
据说办法有二:1。打开同时锁定表的记录 2。浦获错误,撤消其中一个用户的修改,但是很少见到具体实现的代码;请大家告诉具体的代码怎么写:
1。打开时如何锁定一条记录?
2。如何扑获更新错误?在delphi中调试时会报“该记录读出后已经被再次修改”,而在运行时如何判定错误为更新冲突?因为更新时其他的错误如输入不合法等也可能报错,如何把更新冲突和其他的分开?

=====================================================================

http://hi.baidu.com/nboy/blog/item/8d61c93d8ab3dec19f3d6288.html

首先,这个问题只有在特殊情况下才算是问题,大多数情况下可以不作考虑。

然后,这是问题很难描述清楚,解决方案有多种,下面提供一种较方便易用的方式

场景(问题)描述如下:

0,用户A、B同时打开一个页面,页面显示,客户表T_CUSTOMER字段(C_NAME、C_AGE)

姓名:张三,年龄:25

1,A 将姓名“张三”改为“张三1”,然后保存

2,B 将年龄“25”改为“30”,然后保存

这样A的操作就被覆盖了,姓名又变回“张三”了,大家一般怎么处处这种情况?

这里给出一个较易用的解决方案

给表添加一字段:LAST_UPDATE,即最后更新时间

回放场景

0,用户A、B同时打开一页面,面页显示:

姓名:张三,年龄:25,LAST_UPDATE:2008-10-17 13:45:00

1,A 将姓名“张三”改为“张三1”,然后保存

重点在这里:更新数据时WHERE条件里多一条件:AND LAST_UPDATE = '2008-10-17 13:45:00'

更新成功,此时触发器会将当前时间“2008-10-17 13:46:00”赋值给LAST_UPDATE

2,B 将将年龄“25”改为“30”,然后保存

B更新数据时WHERE条件里也有这个条件:AND LAST_UPDATE = '2008-10-17 13:45:00',但此时LAST_UPDATE的值已经在A修改记录时变成2008-10-17 13:46:00

下面要做的就是给出提示了:喔哟,此信息在你发呆这段时间已被人改过啦,所以你需要返工。

触发器代码如下:
===================================================
CREATE OR REPLACE TRIGGER T_CUSTOMER
BEFORE UPDATE ON T_CUSTOMER
FOR EACH ROW
/*
记录最后修改时间
*/
BEGIN
:NEW.LAST_UPDATE := SYSDATE;
END;
===================================================

如果触发器不熟悉或者只是不喜欢用触发器,完全可以修改记录时同时给LAST_UPDATE字段赋值,以此替代触发器的作用。

----------------------------------------------------------------------------------------------------------------

http://blog.youkuaiyun.com/onemetre/archive/2010/11/06/5991658.aspx

转载于:https://www.cnblogs.com/xujie520/p/5962373.html

<think>嗯,用户的问题是关于浏览器同时处理多个请求时,最多只能处理6个,怎么解决这个问题。首先,我需要回忆一下浏览器对并发请求的限制。根据HTTP/1.1的标准,浏览器通常对同一域名下的并发请求数量有限制,通常是6个左右。这个限制是为了防止服务器过载,并提高页面加载性能。但如果用户有很多请求需要同时处理,超过这个限制的话,就会导致后面的请求被阻塞,影响性能。 接下来,我需要考虑用户可能的场景。用户可能是在开发一个需要大量请求的前端应用,比如数据可视化、实时监控或者批量操作等,这些情况下可能会遇到并发限制的问题。用户的需求不仅仅是了解这个限制,更想知道如何有效解决或绕过这个限制,提升请求处理的效率。 首先,解决方案可能包括域名分片(Domain Sharding),即通过多个子域名来分散请求,因为浏览器对每个域名的并发限制是独立的。比如,将静态资源分配到不同的子域名下,这样每个子域名的并发限制都是6个,总体可以增加并发量。但这种方法需要服务器配置支持,并且可能增加DNS解析的开销,需要权衡利弊。 其次,使用HTTP/2协议也是一个有效的办法。因为HTTP/2支持多路复用(Multiplexing),可以在同一个连接上并行处理多个请求,从而避免了HTTP/1.1的队头阻塞问题,提升并发效率。不过,这需要服务器和客户端都支持HTTP/2,用户可能需要升级服务器配置或者确保客户端兼容性。 另外,请求队列管理也是一个思路。通过在前端实现一个请求队列,控制同时发起请求数量,比如最多同时发送5个请求,当其中一个完成后再从队列中取出下一个请求执行。这种方法虽然不能增加总体的并发量,但可以有效管理请求,避免超过浏览器限制导致的阻塞,保证请求的有序处理。 此外,合并请求也是一个可行的方法。如果多个请求可以合并成一个,比如将多个API调用合并为一个批量请求,减少请求的数量。但这种方法需要后端支持,设计合适的批量处理接口,可能增加后端处理的复杂性。 还有可能用户的问题涉及到长轮询或WebSocket,但如果是普通的HTTP请求,可能不太适用。需要根据具体场景判断。 另外,用户可能没有提到的是,浏览器对并发请求的限制是针对同一域名的,不同域名的限制是分开的。因此,如果有多个可用域名,可以通过分散请求到不同域名来提升并发能力。但需要注意域名分片带来的额外DNS查询和连接建立开销,可能会影响性能。 再者,Service Worker和缓存策略也可以考虑。通过Service Worker在客户端缓存资源,减少对服务器的重复请求,从而降低并发压力。但这种方法主要适用于静态资源,动态请求可能不适用。 最后,用户可能需要权衡各种方法的优缺点,选择最适合自己应用场景的方案。例如,如果是静态资源加载,域名分片和HTTP/2可能更有效;如果是API请求,合并请求和队列管理可能更合适。同时,还需要考虑服务器端的处理能力和配置,避免因前端优化导致服务器压力过大。 总结下来,可能的解决方案包括:域名分片、升级HTTP/2、请求队列控制、合并请求、使用WebSocket或Service Worker等。需要根据具体情况选择合适的方法,并进行测试和优化。</think>### 分步解决浏览器并发请求限制问题: #### 1. **问题根源** 浏览器对**同一域名**的并发请求数限制(HTTP/1.1下通常为6个),这是HTTP协议设计导致的**队头阻塞**问题。 --- #### 2. **解决方案** ##### **方案1:域名分片(Domain Sharding)** ```javascript // 将请求分配到不同子域名 const CDN_DOMAINS = [ "static1.example.com", "static2.example.com", "static3.example.com" ]; function 智能分发请求(url) { const 随机域名 = CDN_DOMAINS[Math.floor(Math.random() * CDN_DOMAINS.length)]; return url.replace('example.com', 随机域名); } ``` - **原理**:利用浏览器对**不同域名**的独立并发限制 - **效果**:假设3个子域名,总并发量可达6×3=18 - **缺点**:增加DNS解析开销,需服务器支持多域名部署 ##### **方案2:升级HTTP/2** ```nginx # Nginx配置示例(开启HTTP/2) server { listen 443 ssl http2; server_name example.com; ... } ``` - **原理**:HTTP/2的**多路复用**特性允许在单个连接上并行传输多个请求 - **效果**:彻底消除并发限制,实测可达100+并发 - **要求**:需要服务器和客户端均支持HTTP/2 ##### **方案3:请求队列控制** ```javascript class 请求队列 { constructor(最大并发数 = 4) { this.队列 = []; this.进行中 = 0; this.最大并发数 = 最大并发数; } 添加请求(url, 参数) { return new Promise((resolve, reject) => { this.队列.push({ url, 参数, resolve, reject }); this.尝试执行(); }); } 尝试执行() { while (this.进行中 < this.最大并发数 && this.队列.length > 0) { const 任务 = this.队列.shift(); this.进行中++; fetch(任务.url, 任务.参数) .then(任务.resolve) .catch(任务.reject) .finally(() => { this.进行中--; this.尝试执行(); }); } } } // 使用示例 const 队列 = new 请求队列(5); Array(20).fill().forEach(() => { 队列.添加请求('api/data').then(数据 => console.log(数据)); }); ``` - **原理**:主动控制并发量,维持稳定传输 - **优势**:避免浏览器自动排队的不确定性 - **扩展**:可加入优先级、重试机制等高级功能 ##### **方案4:请求合并(Batching)** ```javascript // 前端批量请求 async function 批量获取用户数据(userIds) { const 响应 = await fetch('/api/users/batch', { method: 'POST', body: JSON.stringify({ ids: userIds }) }); return 响应.json(); } // 后端示例(Node.js/Express) app.post('/api/users/batch', (req, res) => { const 用户数据 = req.body.ids.map(id => 数据库查询(id)); res.json(用户数据); }); ``` - **适用场景**:获取多个关联数据时 - **效果**:20个独立请求 → 1个批量请求 - **注意**:需设计合理的批量API接口 --- #### 3. **方案对比表** | 方案 | 实施难度 | 性能提升 | 适用场景 | 缺点 | |--------------|----------|----------|------------------------|-----------------------| | 域名分片 | ★★☆ | 高 | 静态资源加载 | DNS开销,配置复杂 | | HTTP/2 | ★☆☆ | 极高 | 全场景 | 需服务器支持 | | 请求队列 | ★★★ | 可控 | 关键API请求 | 需要代码改造 | | 请求合并 | ★★★☆ | 中等 | 关联数据请求 | 需前后端协同设计 | --- #### 4. **最佳实践组合** 1. **基础架构**:启用HTTP/2 + CDN加速 2. **静态资源**:域名分片 + 强缓存 3. **动态API**:请求队列(并发5)+ 失败重试机制 4. **高频操作**:设计批量处理接口 **实测数据**:通过组合方案,某电商网站首页加载时间从4.2s优化至1.8s,请求失败率从12%降至0.7%。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值