100分 找ajax问题

我现在在路上 2014-07-02 03:00:53
现在项目中的业务编号是用模版生成的,且业务编号是在创建业务的时候显示出来的,每个业务有个唯一的业务编号。所以在多人操作的时候就要对业务编号确保唯一性。
现在A操作添加了一个业务,编号为XX0702X01;在A添加业务的时候,B也创建了业务,编号也为XX0702X01(以为这个是根据数据库中最大编号和模版生成的),为了让A,B的编号不一样,前台有个js方法ChangeNo,它通过ajax访问后台进行对前台页面的业务编号进行修改,一般每隔一点时间就执行一次且在提交的时候也调用了ChangeNo,但为什么偶尔还会出现相同编号的问题?
ajax的async为false。
有没有更好的方式保证编号的唯一性?
...全文
511 30 打赏 收藏 转发到动态 举报
写回复
用AI写文章
30 条回复
切换为时间正序
请发表友善的回复…
发表回复
卖水果的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 的回复:
这个编号,应该在保存完成后,再回显给用户,你的设计思想,在用户比较少时,才实用。
这不是我的设计思路,老项目的....
  • 打赏
  • 举报
回复
单纯从技术上来说,在数据库中的处理“提交”操作时才去重新计算业务编号,由于关系数据库通常都有默认的“数据库事务”保护机制,可以保证业务编号唯一。 但是如果你的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 编号;; }
在前台提交的时候,后台是有验证的,基本上杜绝了在数据库出现重复的可能。但是在前台的时候取编号后是会有一段等用户添数据的时间的,如果,用户填表的时候再有人添加数据并提交(提交前台验证中有ChangeNo的方法),所以提交的时候会有次更新业务编号的,后台也有验证。 我想问的是在提交的过程中,有ChangeNo为什么偶尔还会触发后台的验证(业务编号重复的验证)? 至于sp1234说的预留的方法,我之前在我写的winform中想过和用过,为多线程分数据区,并lock,这个可以提交效率且也不会出现同时操作引发的各种问题。但,这是个老项目了,不能让我各种尝试,大的改动的.... 至于bwangel说的lock,这个是不行的,因为用户打开页面的时候就会获取一个业务编号,这个业务编号是新的;另个人再打开再获取的是和签个人一样的(如果前一个人没提交的话),但他也是新的,因为这个业务编号在数据库未有人使用。当然,如果lock是加在提交到时候,这是能杜绝用户同时操作绕过后台验证的可能.....但我问的不是这个..... 其实如果我在后台进行这样操作并独自更新编号会影响用户体验....你想用户记得我的编号是07,找的时候没有找到...
我现在在路上 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
  • 打赏
  • 举报
回复
这个编号,应该在保存完成后,再回显给用户,你的设计思想,在用户比较少时,才实用。
  • 打赏
  • 举报
回复
如果是给正规大企业、政府做项目,后者比较稳定和科学,因为没有什么奇技淫巧而是突出了流程。 如果是给小单位随便做个程序,或者不太懂IT的大公司胡乱做个OA程序,那么使用前者。因为所有初学者都似乎只能看懂前者。
  • 打赏
  • 举报
回复
调用ChangeNo的时间,与最终数据被后台保存的时间,总是有点时间差的。如果你不考虑这个客观的逻辑,那么别的许多什么“看起来挺技术似地”的想法都是多余。 有两种方法可以解决。 第一,貌似比较简单,就是放弃ChangeNo最终决定权,改变你的前端业务逻辑结果,不但有ChangeNo提取编号,“提交操作”的后台动作也产生编号并且反馈新编号(可能与最后一次调用ChangeNo结果不同)给前端去。 第二种方式是预先解决编号问题。也就是说你应该预先“放号”,例如先放1000个号到一个数据库表中,那么一个业务创建的时候,同时就从这里“取走”一个编号。然后一旦这个业务被放弃了(比如说对于那些前端页面中断使用的业务,可以在每天凌晨判断其“创建状态”已经超时,从而删除这个正在创建重的业务),那么就把编号放回到放号表中,供其它业务再次使用。
bwangel 2014-07-02
  • 打赏
  • 举报
回复
你也可以用数据库的自增列来形成编号,这样建立在数据库架构基础上的编号绝对是不重复的。 至于显示方式,你可以用格式化成对应的“业务编号”
bwangel 2014-07-02
  • 打赏
  • 举报
回复
服务端必须有专门的编号服务,并且访问是保证互斥的。这样就不会产生重复编号了。 object obj =new object(); lock(obj){ 编号 ++; return 编号;; }
加载更多回复(10)

62,025

社区成员

发帖
与我相关
我的任务
社区描述
.NET技术交流专区
javascript云原生 企业社区
社区管理员
  • ASP.NET
  • .Net开发者社区
  • R小R
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告

.NET 社区是一个围绕开源 .NET 的开放、热情、创新、包容的技术社区。社区致力于为广大 .NET 爱好者提供一个良好的知识共享、协同互助的 .NET 技术交流环境。我们尊重不同意见,支持健康理性的辩论和互动,反对歧视和攻击。

希望和大家一起共同营造一个活跃、友好的社区氛围。

试试用AI创作助手写篇文章吧