该帖已经被评为隐藏帖
|
|
---|---|
作者 | 正文 |
发表时间:2009-08-10
这么简单的东西搞得这么复杂.
你要说清楚插入什么数据才会出现这种情况. 你把表设计好就行了. 你N太APP SERVER都是只一台DB. 根据你的业务把主键设计好就行了. 为何会出现两个字段肯定相同的情况? 那就说明这两个字段不适合做PK. 你再根据业务类型建立个PK就行了. 这明明就是一个表结构设计的业务问题. 这里非要搞成一个技术贴. 不懂不懂. 连锁都搞出来了.. |
|
返回顶楼 | |
发表时间:2009-08-10
这个可以在设计上加于考虑
如果这个记录只有主键约束,则可以考虑主键在插入的时候生成,或者是使用sequence。 如果有其他的约束,可以先锁住该记录,比如oracle的select **** for update 然后再去插入或者更新操作。 |
|
返回顶楼 | |
发表时间:2009-08-10
最后修改:2009-08-10
你那是跨进程的东西,加上sychronized有用么?服务器A上的实例跟服务器B上的实例互斥?
|
|
返回顶楼 | |
发表时间:2009-08-10
pipilu 写道 你那是跨进程的东西,加上sychronized有用么?服务器A上的实例跟服务器B上的实例互斥?
不是, 那个是防止2个用户在同一台web服务器新增同样的数据用的 |
|
返回顶楼 | |
发表时间:2009-08-10
比较支持弄个专门服务器专门处理数据库事务,其它服务器直接调用它的增删改查的接口来进行操作。对于单机操作的话应该就不会出现楼主所担心的顾虑。
|
|
返回顶楼 | |
发表时间:2009-08-10
by5739 写道 pipilu 写道 你那是跨进程的东西,加上sychronized有用么?服务器A上的实例跟服务器B上的实例互斥?
不是, 那个是防止2个用户在同一台web服务器新增同样的数据用的 那这就不只跟多个Web应用服务器有关系了,最好能从业务上避免这种提交。 |
|
返回顶楼 | |
发表时间:2009-08-10
zelsa 写道 把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子,是不是有些浪费了,而且SAVA请求过多,是不是会网络堵塞,有更好的解决方案吗。 |
|
返回顶楼 | |
发表时间:2009-08-10
treblesoftware 写道 zelsa 写道 把save交给一台机器处理,然后暴露API给其他机器使用
如果这样子,是不是有些浪费了,而且SAVA请求过多,是不是会网络堵塞,有更好的解决方案吗。 交给一台机器也有并发的问题吧 是否考虑使用MQ的queue,所有的web发送到mq上,有一个消费者消费这些数据 这种方式有几个问题: 1、异步,不知业务允许 2、消费稍微有些慢 ps. 为什么是会员设置的数据,但是这个表有不和userId有关联。 |
|
返回顶楼 | |
发表时间:2009-08-10
1.针对这两个字段做唯一索引;
2.然后web服务器上直接插入,抓特定的Exception判断是不是违反了唯一性。 |
|
返回顶楼 | |
发表时间:2009-08-11
楼主没有把需求说的太清楚,从楼主的意思来看,只有唯一存放的APP逻辑才好解决。
否则你这种复杂判断唯一性的情况,靠数据库解决不了的。 |
|
返回顶楼 | |