双11狂欢大促

盲盒赢 定制羽绒服

开启惊喜盲盒，抽取你的专属好礼

— 惊喜奖品抢先看 —

超级年卡50元券

周边70元券

手机支架

一拖三数据线

雨伞

运动毛巾

电动牙刷

VIP月卡

机械键盘

定制羽绒服

超级年卡50元券

周边70元券

手机支架

一拖三数据线

雨伞

运动毛巾

电动牙刷

VIP月卡

机械键盘

定制羽绒服

100分找ajax问题

2014-07-02 03:00:53 600 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

我现在在路上墨衍会员 · AI 创作全网分发关注 + 加入社区

AJAX(1):原生AJAX,HTTP协议,Ajax环境配置,AJAX发送请求，AJAX请求中的问题 AJAX全程为Asynchronous Javascript And XML,异步的js和XML通过AJAX 可以在浏览器中向服务器发送异步请求，最大的优势：无刷新获取数据。AJAX 不是新的编程语言，而是一种将现有的标准组合在一起使用的新方式。阅读详情

现在项目中的业务编号是用模版生成的，且业务编号是在创建业务的时候显示出来的，每个业务有个唯一的业务编号。所以在多人操作的时候就要对业务编号确保唯一性。
现在A操作添加了一个业务，编号为XX0702X01;在A添加业务的时候，B也创建了业务，编号也为XX0702X01(以为这个是根据数据库中最大编号和模版生成的),为了让A,B的编号不一样，前台有个js方法ChangeNo，它通过ajax访问后台进行对前台页面的业务编号进行修改，一般每隔一点时间就执行一次且在提交的时候也调用了ChangeNo,但为什么偶尔还会出现相同编号的问题？
ajax的async为false。
有没有更好的方式保证编号的唯一性？

...全文

AJAX请求及解决跨域问题 AJAX其实就是异步的js和xml通过ajax可以在浏览器中发送异步请求。最大优势无刷新获取数据优点1.可以无需刷新页面与服务器进行通信2.允许根据用户事件更新部分页面内容当然也存在其缺点问题比如跨域问题等！... 阅读详情

我现在在路上

.NET社区 62,274 成员 668,968 内容

+ 关注 + 加入社区

切换为时间正序

卖水果的net 2014-07-04

打赏
举报

引用 24 楼 ta_wuhen 的回复:

[quote=引用 21 楼 wmxcn2000 的回复:] 这个编号，应该在保存完成后，再回显给用户，你的设计思想，在用户比较少时，才实用。

这不是我的设计思路，老项目的....[/quote] 老项目维护起来，是挺费劲的，有的还没有文档、文档不全等情况。

JFMark 2014-07-04

打赏
举报

oh，忘记回答你那个“为什么偶尔还会出现相同编号的问题？” +++++++++++++++++++++++++++++++++++++++++++++ 首先，你在客户端用async为false取消异步，这毫无意义多个用户有各自的操作行为，你的async只能管当前用户，管不到其他用户，所以保证不了所有用户的同步 -------- 其次，就算你保证了所有用户行为的同步，你也保证不了数据库的同步数据库的读操作是异步的，也就是说多个用户能同时读取，这样获得的最大编号就是一样的你也能看见是偶尔，如果用户数量一多，操作时间一长，你会发现这不是偶尔而是必然当然，同步数据库的读操作也是没有意义的 -------- 综上，你是不可能保证多用户同一时间读行为唯一。所以你这种操作，“偶尔还会出现相同编号”是必然事件

JFMark 2014-07-04

打赏
举报

看完LZ的需求就是要保证用户记录的和实际录入的编号是一致的，但你又不能保证初始提供编号的唯一性 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 在这种情况下采用SP的放号策略是可行的，但是逻辑改动太大 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 其实可以变种一下你在每天0点时候取数据库最大编号之后用application记录进行此操作的次数然后最大编号加上这个次数产生新的编号这样就能保证编号的唯一性缺点就是当用户放弃行为的时候，那个编号就浪费掉了这样保证了编号的唯一性和顺序性，但不保证连续性

我现在在路上 2014-07-04

打赏
举报

嗯，谢谢大家的想法。。。加贴给分，，

我现在在路上 2014-07-04

打赏
举报

引用 22 楼 zifengshen1981 的回复:

主键唯一啊,取客户端的session id 把,而且保证一台机器只能打开一个登陆页面

主键是唯一的，主键不是这个编号，但这个也要唯一，不唯一是到不了数据库的，这都验证好了。

我现在在路上 2014-07-04

打赏
举报

引用 23 楼 lhl84013686 的回复:

不让用户自己输入业务编号了，自己输入什么格式都有，多不美观，改成后台生成。例如XXX20140703001，XXX20140703002，XXX20140703003。这样也不算难记，个人感觉用户也很少去记这些编号，一般也就记住个名称

就不是用户输入的，是后台生成显示出来的。。

我现在在路上 2014-07-04

打赏
举报

引用 21 楼 wmxcn2000 的回复:

这个编号，应该在保存完成后，再回显给用户，你的设计思想，在用户比较少时，才实用。

这不是我的设计思路，老项目的....

以专业开发人员为伍 2014-07-03

打赏
举报

单纯从技术上来说，在数据库中的处理“提交”操作时才去重新计算业务编号，由于关系数据库通常都有默认的“数据库事务”保护机制，可以保证业务编号唯一。但是如果你的ChangeNo是在这个事务之前的一个事务中的查询（或者修改），而不是在“一个原子的”事务中，就算是两个操作相隔仅仅10毫秒，这个时间间隔也足够产生数据不一致性的了。

踏平扶桑 2014-07-03

打赏
举报

引用 18 楼 ta_wuhen 的回复:

[quote=引用 15 楼 sp1234 的回复:] 单纯从技术上来说，在数据库中的处理“提交”操作时才去重新计算业务编号，由于关系数据库通常都有默认的“数据库事务”保护机制，可以保证业务编号唯一。但是如果你的ChangeNo是在这个事务之前的一个事务中的查询（或者修改），而不是在“一个原子的”事务中，就算是两个操作相隔仅仅10毫秒，这个时间间隔也足够产生数据不一致性的了。

引用 11 楼 bwangel 的回复:

服务端必须有专门的编号服务，并且访问是保证互斥的。这样就不会产生重复编号了。 object obj =new object(); lock(obj){ 编号 ++; return 编号;; }

在前台提交的时候，后台是有验证的，基本上杜绝了在数据库出现重复的可能。但是在前台的时候取编号后是会有一段等用户添数据的时间的，如果，用户填表的时候再有人添加数据并提交(提交前台验证中有ChangeNo的方法)，所以提交的时候会有次更新业务编号的，后台也有验证。我想问的是在提交的过程中，有ChangeNo为什么偶尔还会触发后台的验证(业务编号重复的验证)？至于sp1234说的预留的方法，我之前在我写的winform中想过和用过，为多线程分数据区，并lock，这个可以提交效率且也不会出现同时操作引发的各种问题。但，这是个老项目了，不能让我各种尝试，大的改动的.... 至于bwangel说的lock，这个是不行的，因为用户打开页面的时候就会获取一个业务编号，这个业务编号是新的；另个人再打开再获取的是和签个人一样的(如果前一个人没提交的话),但他也是新的，因为这个业务编号在数据库未有人使用。当然，如果lock是加在提交到时候，这是能杜绝用户同时操作绕过后台验证的可能.....但我问的不是这个..... 其实如果我在后台进行这样操作并独自更新编号会影响用户体验....你想用户记得我的编号是07，找的时候没有找到...[/quote] 提交的时候在数据库中生成业务编号，前台打开添加界面只是一个流水号（每次打开都会更新某个字段的值，下个打开的取这个值+1，或者某种规则）。

十三- 2014-07-03

打赏
举报

这个编号算法是死的么，不能更改？要是可以改，获取当前utc时间再加一些随机数，那永远都不会出现重复

我现在在路上 2014-07-03

打赏
举报

引用 15 楼 sp1234 的回复:

单纯从技术上来说，在数据库中的处理“提交”操作时才去重新计算业务编号，由于关系数据库通常都有默认的“数据库事务”保护机制，可以保证业务编号唯一。但是如果你的ChangeNo是在这个事务之前的一个事务中的查询（或者修改），而不是在“一个原子的”事务中，就算是两个操作相隔仅仅10毫秒，这个时间间隔也足够产生数据不一致性的了。

引用 11 楼 bwangel 的回复:

服务端必须有专门的编号服务，并且访问是保证互斥的。这样就不会产生重复编号了。 object obj =new object(); lock(obj){ 编号 ++; return 编号;; }

我现在在路上 2014-07-03

打赏
举报

引用 5 楼 xxoome 的回复:

“它通过ajax访问后台进行对前台页面的业务编号进行修改，一般每隔一点时间就执行一次....”这个用来干这事，你也太扯了。 A和B一样，B不能入库前不能先去库中检测下,再入库么？

都有检测的，只是想找个好的方法不出现在后台检测重复的时候出现重复

我现在在路上 2014-07-03

打赏
举报

引用 1 楼 Z65443344 的回复:

提交之前先去查一下最大编号是多少,而不是没提交的时候定时查. 数据库里将编号设置为主键,这样即使是在一个用户查询和插入的这点时间里插入了记录,也提示提交失败,而不会出现相同编号的问题.

在后台有验证的，如果重复是会提示编号重复的。问题是想让用户感觉不到这个，因为一旦出现在这个问题，用户是不知道如何解决的

lhl84013686 2014-07-03

打赏
举报

不让用户自己输入业务编号了，自己输入什么格式都有，多不美观，改成后台生成。例如XXX20140703001，XXX20140703002，XXX20140703003。这样也不算难记，个人感觉用户也很少去记这些编号，一般也就记住个名称

紫魂一号 2014-07-03

打赏
举报

主键唯一啊,取客户端的session id 把,而且保证一台机器只能打开一个登陆页面

卖水果的net 2014-07-03

打赏
举报

这个编号，应该在保存完成后，再回显给用户，你的设计思想，在用户比较少时，才实用。

以专业开发人员为伍 2014-07-02

打赏
举报

如果是给正规大企业、政府做项目，后者比较稳定和科学，因为没有什么奇技淫巧而是突出了流程。如果是给小单位随便做个程序，或者不太懂IT的大公司胡乱做个OA程序，那么使用前者。因为所有初学者都似乎只能看懂前者。

以专业开发人员为伍 2014-07-02

打赏
举报

调用ChangeNo的时间，与最终数据被后台保存的时间，总是有点时间差的。如果你不考虑这个客观的逻辑，那么别的许多什么“看起来挺技术似地”的想法都是多余。有两种方法可以解决。第一，貌似比较简单，就是放弃ChangeNo最终决定权，改变你的前端业务逻辑结果，不但有ChangeNo提取编号，“提交操作”的后台动作也产生编号并且反馈新编号（可能与最后一次调用ChangeNo结果不同）给前端去。第二种方式是预先解决编号问题。也就是说你应该预先“放号”，例如先放1000个号到一个数据库表中，那么一个业务创建的时候，同时就从这里“取走”一个编号。然后一旦这个业务被放弃了（比如说对于那些前端页面中断使用的业务，可以在每天凌晨判断其“创建状态”已经超时，从而删除这个正在创建重的业务），那么就把编号放回到放号表中，供其它业务再次使用。

bwangel 2014-07-02

打赏
举报

你也可以用数据库的自增列来形成编号，这样建立在数据库架构基础上的编号绝对是不重复的。至于显示方式，你可以用格式化成对应的“业务编号”

bwangel 2014-07-02

打赏
举报

服务端必须有专门的编号服务，并且访问是保证互斥的。这样就不会产生重复编号了。 object obj =new object(); lock(obj){ 编号 ++; return 编号;; }

加载更多回复（10）

✦双11狂欢大促✦

100分 找ajax问题

相关推荐

双11狂欢大促

100分找ajax问题