- 浏览: 530507 次
- 性别:
- 来自: 山东济南
文章分类
最新评论
-
dragon_8844:
非常不错,nice
java.util.concurrent 多线程框架 -
wusendong:
很好的文章!受益匪浅,谢谢!
java.util.concurrent 多线程框架 -
SINCE1978:
你也关注并发啊
java.util.concurrent 多线程框架 -
lku1314:
这个不错 刚刚找到这个组建 以前孤陋寡闻了 像lz学习!标 ...
quartz 在WEB中应用小结 -
lliiqiang:
人们对于目标需要的需求明确的去做,对于目标以外的因素是随机的执 ...
flex和后端的数据交互(一)--XML和HTTPService
我们的项目是一个具有工作流特性的B/S系统;现在处于功能测试阶段,前几天一个同事提出一个问题:
系统中的很多工作都必须有步骤的进行,比如,先做计划,然后实施,再查看结果。
系统中的用户权限分为浏览和操作,用户在模块中的权限是交错的,在一个模块可以操作而在另一个模块
只能浏览操作结果。
现在的情况是如果在同一时间有两个或多个对同一模块具有操作权限的用户在这一模块中进行操作的话,可能会引起
操作结果冲突的现象;比如A和B两个人都可以做发电计划,A、B两个人如果在同一时间都给电厂分配电量,那么电厂接到的
发电计划会冲突或者造成数据丢失!
现在我们想到的解决方法是
1.在数据库中给每一个模块建立一个操作步骤存储表,根据步骤标志位的判断解决冲突!
2.在服务器上作一个托盘,实时检测用户登录,当有一个用户在这一模块中进行操作时,进入这一模块的另一用户不管权限大小都
只分配浏览权限,并给用户以提示!
3.通过权限控制,两个对同一模块都具有操作权限的用户,谁先登录本模块谁就有操作权,后登录的只有浏览权;设定先登录用户
使用时间,时间一到再进行操作就需要重新登录,再进入时如果已经有用户在操作就给他分配浏览权限!
第一种方法实现最简单,但是数据交互量增加,交互频繁!
第二种方法实现起来应该比较麻烦,但是更能符合需求;
最后一种缺乏人性化!
请知各位是怎样解决这一问题的?请不吝赐教!
请积极拍砖!
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
你这里依然没有解决如何处理异常中断造成的不正常解锁问题!
其实我觉得既然既然需要系统外沟通,强行进入这个功能还是屏蔽比较好,让他自己退出比较安全。
对于异常解锁,可以设定为锁定人/系统管理员解锁。
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
你这里依然没有解决如何处理异常中断造成的不正常解锁问题!
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
不错!你能说的再具体一些吗?包括实现方式什么的!谢谢!
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
是需求问题,不是设计问题。
流程性的需求有一个重要检查点就是并发性。
如果用户答应你的工作分工建议,这个事情就好办了,不过我猜用户未必肯答应。
因为存在一个工作替代的需求,万一负责南方电厂的人有事,那么就需要别人来替代他的工作。
一个电厂在一个时间周期内(比如一个月/一年)应该只有一份计划,但是只要有权限的人都可以编辑,直到下达为止。
建议以下设计方案:
在计划创建时,确保有一个唯一标识字段,使得不会创建业务上互相冲突的计划。
在每份计划上加一个标志位(锁),采用checkout/checkin的机制,确保任一时刻只有一个人可以修改计划。
(需要处理异常断线的情况)
对于版本的控制:保存最新的修改后的计划和每一次的修改记录(修改人/修改时间/修改内容),一般不需要保存每一次的版本。
建议不错!
项目上个月底刚进行完一次联调,用户现在还没空管这方面的事情那,呵呵!不过以后肯定会说的!
估计你有过CS程序的开发经验,如果你用PB开发实现这种要求很容易,bs应用,用这种方式简单想一下感觉很难或者不灵活。比如使用标志位,当A用户开始做计划,在数据库中记录A用户正在进行,这是后假设A不做了,关闭窗口(或者异常中断了),系统要怎么办,定时删除过期未更新的标志?还是不做处理,等待A用户下次有空了再来继续录入他的计划,在这个过程中其他用户统统不允许录入这个计划。这时候用户可能又要说了,我已经不录了,你为什么不让其他人录?你要怎么办?
确实要解决所有可能存在的问题都不容易;我们现在也没考虑的很深,就是先尝试着做怎样解排他锁的问题!
这位老兄说得问题,我觉得可以用事务来作;初步想法,还没开始搞!
节后再说,呵呵!
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
是需求问题,不是设计问题。
流程性的需求有一个重要检查点就是并发性。
如果用户答应你的工作分工建议,这个事情就好办了,不过我猜用户未必肯答应。
因为存在一个工作替代的需求,万一负责南方电厂的人有事,那么就需要别人来替代他的工作。
一个电厂在一个时间周期内(比如一个月/一年)应该只有一份计划,但是只要有权限的人都可以编辑,直到下达为止。
建议以下设计方案:
在计划创建时,确保有一个唯一标识字段,使得不会创建业务上互相冲突的计划。
在每份计划上加一个标志位(锁),采用checkout/checkin的机制,确保任一时刻只有一个人可以修改计划。
(需要处理异常断线的情况)
对于版本的控制:保存最新的修改后的计划和每一次的修改记录(修改人/修改时间/修改内容),一般不需要保存每一次的版本。
这位老兄说得对,我们现在的需求就是这样的。既然要做这方面的功能处理,就要处理好,处理的人性话,尽量替用户着想!呵呵!
现在这个问题由技术问题变成了管理问题了,在多年前找解决多人checkout提交时出现需要merge version问题时就已经在CVS手册上看到,类似的版本冲突什么的是个管理问题,而不是技术问题。和daoge的问题类似,所以在工具上如果用户不是强烈要求的话,建议不要加上太多的限制而仅仅是增加一些提示,剩下的问题是客户的管理问题,划分区域是一个好的解决办法。
估计你有过CS程序的开发经验,如果你用PB开发实现这种要求很容易,bs应用,用这种方式简单想一下感觉很难或者不灵活。比如使用标志位,当A用户开始做计划,在数据库中记录A用户正在进行,这是后假设A不做了,关闭窗口(或者异常中断了),系统要怎么办,定时删除过期未更新的标志?还是不做处理,等待A用户下次有空了再来继续录入他的计划,在这个过程中其他用户统统不允许录入这个计划。这时候用户可能又要说了,我已经不录了,你为什么不让其他人录?你要怎么办?
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
你说这是一个问题,那需求是不是“A只能修改他自己编辑的计划1,不能修改计划2”
这是一个用户需求 还是 你们的系统现在是这么设计但不符合用户需求?
另外,不同用户的计划间是否可能有冲突?如果产生冲突,业务上如何解决这个问题?
我认为这首先是一个业务问题。
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
这位老兄说得对,我们现在的需求就是这样的。既然要做这方面的功能处理,就要处理好,处理的人性话,尽量替用户着想!呵呵!
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
你说这是一个问题,那需求是不是“A只能修改他自己编辑的计划1,不能修改计划2”
这是一个用户需求 还是 你们的系统现在是这么设计但不符合用户需求?
另外,不同用户的计划间是否可能有冲突?如果产生冲突,业务上如何解决这个问题?
我认为这首先是一个业务问题。
一个步骤中有很多任务,一个任务也可以出现很多结果,这很多结果可能都是正确的;如:给电厂分配发电量,只要是在机组发电负荷之下的都可以认为是正确的!
我没用过Version字段,不知道是不是要修改数据库,即便是现在修改代码,工作量也不小啊!
再说这是依赖于hibernate,如果用其他映射框架呢?
查查用Hibernate的Version字段的用法,呵呵!
Hibernate的Version是个好东西,JPA的annotaion中都有,看到了都觉得亲切,呵呵。
Version是需要在表上增加一个字段,用于表示数据操作的版本,用户更新一条记录时,将Version字段的值加1。当更新前发现Version字段的值不等于自己记录中的值时,说明被别人更新过了,需要进行异常处理。
用Hibernate的Version的话自己不需要做什么代码改动,只需要改配置文件,表中增加Version字段。不用Hibernate的话,自己实现也不复杂。
不知道楼主对一个任务中的多个操作是如何做事务管理的,感觉每一个任务定一个事务,将多个原子操作包括起来,当一处原子操作有Version的冲突,整个任务全部回滚。不知道这样对你的代码改动大不大
说得也对,一个标志位可能也解决不了问题,标志位多了就怕自己都搞乱了!唉!
是这样的,每个人制定的计划都是根据各自对业务的理解而来的,一样的可能性不大!
还有一点就是,我们的功能基本全部实现了,现在正在由用户进行功能测试,项目再有几个月就要投运了!如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的!
昨天又问了一下项目经理,如果暂时没有好的解决方法,就只能从权限上控制,暂时每一个模块只有一个具有操作权限的用户!
唉!
各位以前的B/S项目中没遇到这样的需求吗?
看来是我的表达方式有点问题,再重复一下,有没有这样的情况:
A做了计划1,B做了计划2。
A可以改计划1,B可以改计划2,这两个操作可以同时进行
A也可以改计划2,B可以改计划1,这两个操作也可以同时进行
A/B不能同时改计划1
A/B不能同时改计划2
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
计划下达之后就不能再修改,数据就被锁定了!计划下达前有操作权限的用户就可以对现有的所有计划进行修改!
我搜索了一下,这个问题的解决方法不多,呵呵!也可能是我搜索的不全面!我觉得这可能就是项目最初设计时的一个疏漏!
看来如果不能从技术上解决那就只能从业务上解决:工作分工!
是这样的,每个人制定的计划都是根据各自对业务的理解而来的,一样的可能性不大!
还有一点就是,我们的功能基本全部实现了,现在正在由用户进行功能测试,项目再有几个月就要投运了!如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的!
昨天又问了一下项目经理,如果暂时没有好的解决方法,就只能从权限上控制,暂时每一个模块只有一个具有操作权限的用户!
唉!
各位以前的B/S项目中没遇到这样的需求吗?
看来是我的表达方式有点问题,再重复一下,有没有这样的情况:
A做了计划1,B做了计划2。
A可以改计划1,B可以改计划2,这两个操作可以同时进行
A也可以改计划2,B可以改计划1,这两个操作也可以同时进行
A/B不能同时改计划1
A/B不能同时改计划2
系统中的很多工作都必须有步骤的进行,比如,先做计划,然后实施,再查看结果。
系统中的用户权限分为浏览和操作,用户在模块中的权限是交错的,在一个模块可以操作而在另一个模块
只能浏览操作结果。
现在的情况是如果在同一时间有两个或多个对同一模块具有操作权限的用户在这一模块中进行操作的话,可能会引起
操作结果冲突的现象;比如A和B两个人都可以做发电计划,A、B两个人如果在同一时间都给电厂分配电量,那么电厂接到的
发电计划会冲突或者造成数据丢失!
现在我们想到的解决方法是
1.在数据库中给每一个模块建立一个操作步骤存储表,根据步骤标志位的判断解决冲突!
2.在服务器上作一个托盘,实时检测用户登录,当有一个用户在这一模块中进行操作时,进入这一模块的另一用户不管权限大小都
只分配浏览权限,并给用户以提示!
3.通过权限控制,两个对同一模块都具有操作权限的用户,谁先登录本模块谁就有操作权,后登录的只有浏览权;设定先登录用户
使用时间,时间一到再进行操作就需要重新登录,再进入时如果已经有用户在操作就给他分配浏览权限!
第一种方法实现最简单,但是数据交互量增加,交互频繁!
第二种方法实现起来应该比较麻烦,但是更能符合需求;
最后一种缺乏人性化!
请知各位是怎样解决这一问题的?请不吝赐教!
请积极拍砖!
评论
35 楼
xugq035
2007-01-27
magice 写道
引用
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
你这里依然没有解决如何处理异常中断造成的不正常解锁问题!
其实我觉得既然既然需要系统外沟通,强行进入这个功能还是屏蔽比较好,让他自己退出比较安全。
对于异常解锁,可以设定为锁定人/系统管理员解锁。
34 楼
magice
2007-01-26
引用
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
你这里依然没有解决如何处理异常中断造成的不正常解锁问题!
33 楼
daoger
2007-01-04
clamp 写道
jian7456 写道
我们也遇到这种问题,一般是记录的同步操作问题.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
不错!你能说的再具体一些吗?包括实现方式什么的!谢谢!
32 楼
clamp
2007-01-02
jian7456 写道
我们也遇到这种问题,一般是记录的同步操作问题.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
锁肯定是要记录用户信息的。
由于异常断线或其他原因造成不能正常解锁是比较麻烦的。
我们以前采用过这样一种异常解锁机制:
假设有A/B两个用户,A用户先操作,通过checkout操作,对某条记录加锁。
随后B用户操作,这时给B用户一个提示:“A用户正在操作,是否需要强行进入?”
(这里B用户要和A用户进行系统外的沟通)
B用户可以选择强行进入,这时就直接把A用户的锁强行替换为B用户的锁,A用户如果试图对此记录进行操作,就会得到一个类似的提示:“B用户正在操作,是否需要强行进入?”
用户一般都可以接受这种操作模式的。
31 楼
daoger
2007-01-02
clamp 写道
daoger 写道
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
是需求问题,不是设计问题。
流程性的需求有一个重要检查点就是并发性。
如果用户答应你的工作分工建议,这个事情就好办了,不过我猜用户未必肯答应。
因为存在一个工作替代的需求,万一负责南方电厂的人有事,那么就需要别人来替代他的工作。
一个电厂在一个时间周期内(比如一个月/一年)应该只有一份计划,但是只要有权限的人都可以编辑,直到下达为止。
建议以下设计方案:
在计划创建时,确保有一个唯一标识字段,使得不会创建业务上互相冲突的计划。
在每份计划上加一个标志位(锁),采用checkout/checkin的机制,确保任一时刻只有一个人可以修改计划。
(需要处理异常断线的情况)
对于版本的控制:保存最新的修改后的计划和每一次的修改记录(修改人/修改时间/修改内容),一般不需要保存每一次的版本。
建议不错!
项目上个月底刚进行完一次联调,用户现在还没空管这方面的事情那,呵呵!不过以后肯定会说的!
30 楼
daoger
2007-01-02
newroc 写道
Lucas Lee 写道
我认为用Version不是解决这类问题的正确方法。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
估计你有过CS程序的开发经验,如果你用PB开发实现这种要求很容易,bs应用,用这种方式简单想一下感觉很难或者不灵活。比如使用标志位,当A用户开始做计划,在数据库中记录A用户正在进行,这是后假设A不做了,关闭窗口(或者异常中断了),系统要怎么办,定时删除过期未更新的标志?还是不做处理,等待A用户下次有空了再来继续录入他的计划,在这个过程中其他用户统统不允许录入这个计划。这时候用户可能又要说了,我已经不录了,你为什么不让其他人录?你要怎么办?
确实要解决所有可能存在的问题都不容易;我们现在也没考虑的很深,就是先尝试着做怎样解排他锁的问题!
这位老兄说得问题,我觉得可以用事务来作;初步想法,还没开始搞!
节后再说,呵呵!
29 楼
jian7456
2007-01-02
我们也遇到这种问题,一般是记录的同步操作问题.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
需求状况:操作一般分两步走,第一步显示记录列表,页面有ABC三条记录,
第二步选中其中一条后进入明细页面,提交后将记录转化为另种数据,并将记录的已转化标志设为真.
并发操作状况:有可能两个用户同时选中A记录,进入明细页面,再提交后会生成两条由A记录转化来的新数据,造成数据错误.
构思中的解决方法:在明细页面提交时是根据缓存中的数据生成新数据,如果在提交时根据数据主ID再查次数据库,判断标志位,已转化标志为真时抛异常,阻止提交.
存在问题:1,有些这种操作步骤的数据没有类似标志位.要改动比较麻烦.
2,对数据更新的并发操作可以定义出几种不同等级,孙卫琴的<精通HIBERNATE>中提到,什么可重复读,读未提交,读已提交等.一般更新问题要求并发性低,例如:ABC三条金额的数据,当用户甲操作A时,虽然用户乙也看到A,但不能选择A进行操作.这种情况应该是人为的加标志位上锁,即在选择进入时就操作数据库设标志位,有个麻烦是B/S结构中如何解锁,因为离开当前操作页面有许多方式,可以是点其他链接,也可以是关闭网页.
对于解锁问题的构思:因为判断解锁的情况太复杂,暂时考虑延时的方法,上锁后几分钟内无提交操作,自动解锁,允许用户乙选择数据A操作,问题是此时用户甲仍停留在操作页面,如何让甲的提交操作失败.这时发现锁的标志位应该涉及用户信息,考虑用用户主键当标志位,提交更新时判断标志位是否为当前用户的id,匹配的话才允许提交.
以上全是构思中的,无实践验证,不知对于更新的解锁方法有无更好的.
28 楼
clamp
2007-01-01
daoger 写道
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
是需求问题,不是设计问题。
流程性的需求有一个重要检查点就是并发性。
如果用户答应你的工作分工建议,这个事情就好办了,不过我猜用户未必肯答应。
因为存在一个工作替代的需求,万一负责南方电厂的人有事,那么就需要别人来替代他的工作。
一个电厂在一个时间周期内(比如一个月/一年)应该只有一份计划,但是只要有权限的人都可以编辑,直到下达为止。
建议以下设计方案:
在计划创建时,确保有一个唯一标识字段,使得不会创建业务上互相冲突的计划。
在每份计划上加一个标志位(锁),采用checkout/checkin的机制,确保任一时刻只有一个人可以修改计划。
(需要处理异常断线的情况)
对于版本的控制:保存最新的修改后的计划和每一次的修改记录(修改人/修改时间/修改内容),一般不需要保存每一次的版本。
27 楼
XMLDB
2007-01-01
daoger 写道
Lucas Lee 写道
我认为用Version不是解决这类问题的正确方法。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
这位老兄说得对,我们现在的需求就是这样的。既然要做这方面的功能处理,就要处理好,处理的人性话,尽量替用户着想!呵呵!
现在这个问题由技术问题变成了管理问题了,在多年前找解决多人checkout提交时出现需要merge version问题时就已经在CVS手册上看到,类似的版本冲突什么的是个管理问题,而不是技术问题。和daoge的问题类似,所以在工具上如果用户不是强烈要求的话,建议不要加上太多的限制而仅仅是增加一些提示,剩下的问题是客户的管理问题,划分区域是一个好的解决办法。
26 楼
newroc
2007-01-01
Lucas Lee 写道
我认为用Version不是解决这类问题的正确方法。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
估计你有过CS程序的开发经验,如果你用PB开发实现这种要求很容易,bs应用,用这种方式简单想一下感觉很难或者不灵活。比如使用标志位,当A用户开始做计划,在数据库中记录A用户正在进行,这是后假设A不做了,关闭窗口(或者异常中断了),系统要怎么办,定时删除过期未更新的标志?还是不做处理,等待A用户下次有空了再来继续录入他的计划,在这个过程中其他用户统统不允许录入这个计划。这时候用户可能又要说了,我已经不录了,你为什么不让其他人录?你要怎么办?
25 楼
daoger
2006-12-31
clamp 写道
daoger 写道
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
你说这是一个问题,那需求是不是“A只能修改他自己编辑的计划1,不能修改计划2”
daoger 写道
计划下达前有操作权限的用户就可以对现有的所有计划进行修改!
这是一个用户需求 还是 你们的系统现在是这么设计但不符合用户需求?
另外,不同用户的计划间是否可能有冲突?如果产生冲突,业务上如何解决这个问题?
daoger 写道
看来如果不能从技术上解决那就只能从业务上解决:工作分工!
我认为这首先是一个业务问题。
1.只要有操作权限,他什么计划都可以修改!
2.由于项目要求的比较紧,当初设计的时候用户没有说明可能会有两个或两个以上的人同时操作一个模块,设计人员就没有考虑这个问题!现在项目不久之后就要投运了,用户才又提起这个需求的。
3.明确工作分工,A用户就只能对北方的电厂有操作权,B用户只能对南方的电厂有操作权,A B两个用户的业务划分不能有交集!
24 楼
daoger
2006-12-31
Lucas Lee 写道
我认为用Version不是解决这类问题的正确方法。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
这位老兄说得对,我们现在的需求就是这样的。既然要做这方面的功能处理,就要处理好,处理的人性话,尽量替用户着想!呵呵!
23 楼
clamp
2006-12-31
daoger 写道
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
你说这是一个问题,那需求是不是“A只能修改他自己编辑的计划1,不能修改计划2”
daoger 写道
计划下达前有操作权限的用户就可以对现有的所有计划进行修改!
这是一个用户需求 还是 你们的系统现在是这么设计但不符合用户需求?
另外,不同用户的计划间是否可能有冲突?如果产生冲突,业务上如何解决这个问题?
daoger 写道
看来如果不能从技术上解决那就只能从业务上解决:工作分工!
我认为这首先是一个业务问题。
22 楼
XMLDB
2006-12-31
拜托楼上看清楚人家的需求,电网调配只要不超过负荷就OK,管人家做多少计划呢.
不过,加上一个当前还有谁正在改同一个东西的功能还是很酷的, 又多一个卖点:这可是支持协同工作的产品哦
不过,加上一个当前还有谁正在改同一个东西的功能还是很酷的, 又多一个卖点:这可是支持协同工作的产品哦
21 楼
LucasLee
2006-12-31
我认为用Version不是解决这类问题的正确方法。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
的确,Version是能解决数据并发修改的问题。
但关键看业务需求。
如果A用户,B用户一起做一个计划数据,搞了半天,B用户发现系统提示A用户已经做好了,你这不是浪费人力么?B用户肯定会说,为什么不让我在进入之前提示我A正在做了?或者我做了就提示A不要再做了。
20 楼
leelun
2006-12-31
daoger 写道
leelun 写道
用Hibernate的Version字段,控制每次只能由一人保存数据,如果出现Version冲突,就回滚并重新读取数据
一个步骤中有很多任务,一个任务也可以出现很多结果,这很多结果可能都是正确的;如:给电厂分配发电量,只要是在机组发电负荷之下的都可以认为是正确的!
我没用过Version字段,不知道是不是要修改数据库,即便是现在修改代码,工作量也不小啊!
再说这是依赖于hibernate,如果用其他映射框架呢?
查查用Hibernate的Version字段的用法,呵呵!
Hibernate的Version是个好东西,JPA的annotaion中都有,看到了都觉得亲切,呵呵。
Version是需要在表上增加一个字段,用于表示数据操作的版本,用户更新一条记录时,将Version字段的值加1。当更新前发现Version字段的值不等于自己记录中的值时,说明被别人更新过了,需要进行异常处理。
用Hibernate的Version的话自己不需要做什么代码改动,只需要改配置文件,表中增加Version字段。不用Hibernate的话,自己实现也不复杂。
不知道楼主对一个任务中的多个操作是如何做事务管理的,感觉每一个任务定一个事务,将多个原子操作包括起来,当一处原子操作有Version的冲突,整个任务全部回滚。不知道这样对你的代码改动大不大
19 楼
XMLDB
2006-12-31
在你的环境下,要把冲突分为两种:
1.多个计划的冲突
2.多个用户对同一个计划的冲突
第一个我上面已经说了,要使用带条件的更新,操作完后确认结果正确.在你的例子里如果超出可分配电量范围,很明显就需要返回业务异常提示用户.
第二个,和第一个方法一样,如果发现在更新后发现结果不是自己那个,则需要提示用户或让用户决定是放弃还是覆盖.
在一个操作里,都必须做上面两个检查.
1.多个计划的冲突
2.多个用户对同一个计划的冲突
第一个我上面已经说了,要使用带条件的更新,操作完后确认结果正确.在你的例子里如果超出可分配电量范围,很明显就需要返回业务异常提示用户.
第二个,和第一个方法一样,如果发现在更新后发现结果不是自己那个,则需要提示用户或让用户决定是放弃还是覆盖.
在一个操作里,都必须做上面两个检查.
18 楼
daoger
2006-12-31
XMLDB 写道
按标志位来,在不远的将来就可以看到有一些谁都不能操作的数据了,哈哈
说得也对,一个标志位可能也解决不了问题,标志位多了就怕自己都搞乱了!唉!
17 楼
daoger
2006-12-31
clamp 写道
daoger 写道
clamp 写道
奇怪,大家都觉得自己理解需求了吗?这么迫不及待的给技术解决方案啊……
我问个需求澄清问题:
是否存在以下这种情况,一个模块中有多个实例记录?
比如编辑计划
存在着多份计划,A/B两个用户都有编辑计划的权限,
在同一时刻A/B都能使用编辑计划这个功能,但是只能编辑不同的计划,而不能编辑相同的计划。
我问个需求澄清问题:
是否存在以下这种情况,一个模块中有多个实例记录?
比如编辑计划
存在着多份计划,A/B两个用户都有编辑计划的权限,
在同一时刻A/B都能使用编辑计划这个功能,但是只能编辑不同的计划,而不能编辑相同的计划。
是这样的,每个人制定的计划都是根据各自对业务的理解而来的,一样的可能性不大!
还有一点就是,我们的功能基本全部实现了,现在正在由用户进行功能测试,项目再有几个月就要投运了!如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的!
昨天又问了一下项目经理,如果暂时没有好的解决方法,就只能从权限上控制,暂时每一个模块只有一个具有操作权限的用户!
唉!
各位以前的B/S项目中没遇到这样的需求吗?
看来是我的表达方式有点问题,再重复一下,有没有这样的情况:
A做了计划1,B做了计划2。
A可以改计划1,B可以改计划2,这两个操作可以同时进行
A也可以改计划2,B可以改计划1,这两个操作也可以同时进行
A/B不能同时改计划1
A/B不能同时改计划2
做好的计划都存在数据库中,从库中读取计划时不区分哪个计划是哪个用户编辑的,正是这样就存在了A可以修改计划1,也可以修改计划2的问题!
计划下达之后就不能再修改,数据就被锁定了!计划下达前有操作权限的用户就可以对现有的所有计划进行修改!
我搜索了一下,这个问题的解决方法不多,呵呵!也可能是我搜索的不全面!我觉得这可能就是项目最初设计时的一个疏漏!
看来如果不能从技术上解决那就只能从业务上解决:工作分工!
16 楼
clamp
2006-12-31
daoger 写道
clamp 写道
奇怪,大家都觉得自己理解需求了吗?这么迫不及待的给技术解决方案啊……
我问个需求澄清问题:
是否存在以下这种情况,一个模块中有多个实例记录?
比如编辑计划
存在着多份计划,A/B两个用户都有编辑计划的权限,
在同一时刻A/B都能使用编辑计划这个功能,但是只能编辑不同的计划,而不能编辑相同的计划。
我问个需求澄清问题:
是否存在以下这种情况,一个模块中有多个实例记录?
比如编辑计划
存在着多份计划,A/B两个用户都有编辑计划的权限,
在同一时刻A/B都能使用编辑计划这个功能,但是只能编辑不同的计划,而不能编辑相同的计划。
是这样的,每个人制定的计划都是根据各自对业务的理解而来的,一样的可能性不大!
还有一点就是,我们的功能基本全部实现了,现在正在由用户进行功能测试,项目再有几个月就要投运了!如果采取楼上几位的方法需要大量修改现有表结构的话肯定是不可取的!
昨天又问了一下项目经理,如果暂时没有好的解决方法,就只能从权限上控制,暂时每一个模块只有一个具有操作权限的用户!
唉!
各位以前的B/S项目中没遇到这样的需求吗?
看来是我的表达方式有点问题,再重复一下,有没有这样的情况:
A做了计划1,B做了计划2。
A可以改计划1,B可以改计划2,这两个操作可以同时进行
A也可以改计划2,B可以改计划1,这两个操作也可以同时进行
A/B不能同时改计划1
A/B不能同时改计划2
发表评论
-
java动态编程一例
2009-12-22 08:37 1627Test.java package test; im ... -
tomcat SSL基本配置
2009-11-30 09:25 1533切换到$TOMCAT_HOME下: 1.生成 server ... -
Oracle 10g自带性能监测工具
2009-11-04 09:08 3179安装Oracle 10g时可以选择安装自带的性能监测工具,对于 ... -
Liferay应用界面
2009-09-16 17:26 2239我们用Liferay Portal开发的项目,已有小成,sho ... -
Liferay Iframe Portlet
2009-09-01 08:30 5917The Iframe portlet makes it pos ... -
LifeRay 5.1.2 使用struts1.1时ClassNotFoundException
2009-08-25 10:37 1271今天修改一个portlet时出现 java.lang.Clas ... -
Tomcat 5 中文路径问题
2009-08-06 10:02 1427在tomcat 5下一个动态加载svg图形文件的页面; 页面中 ... -
dhtmlxtree使用中的CharConversionException: isHexDigit
2009-08-04 16:48 2012使用dhtmlxtree时,点击树节点异步加载子节点数据时,在 ... -
程序员五大层次,你属于哪一层?
2009-07-14 13:54 1246软件界一个无 ... -
第一次面别人
2009-05-27 09:40 1714“面”不是吃的,是看的。 从换了工作以后都很忙,周 ... -
liferay中使用struts时jar文件冲突
2009-05-26 13:52 1768异常: java.lang.NoSuchMethodE ... -
犹豫中,不知道该怎么办了!
2009-03-04 10:38 1238先说说我现在的公司, ... -
参数传递的浏览器差异
2008-10-19 22:32 1765情况大体是这样的:一个头页面header.jsp上有一个搜索框 ... -
该死的黑客
2008-09-22 15:06 1446公司一台对外网服务的linux系统数据库服务器,上周五被人破译 ... -
A Tutorial on Clustering Algorithms
2008-07-02 09:50 3115A Tutorial on Clustering Algor ... -
The Examples for Quartz Time Format
2008-05-16 15:02 1807The Examples for Quartz Time Fo ... -
让人头疼的新手
2008-05-13 11:25 5013刚进公司没多久时,领导让我带两个新人(07年7月份毕业的)。他 ... -
昨天参加了一次面试
2008-05-06 11:40 2956象去年这个时候一样, ... -
开发小记
2008-02-13 15:54 15121. 在oracle中字符串拼 ... -
javascript实现日期操作的工具包
2007-12-13 13:39 3345最近一个小项目中用到了dwr,其中使用到了日期型数据;查了一下 ...
相关推荐
1. 用户管理: - 用户登录:用户需输入正确的用户名和经过加密的密码才能进入系统。 - 用户注册:用户填写个人信息,包括密码、性别等,系统会检查用户名的唯一性。 - 个人信息编辑:用户可以随时更新其用户名、...
在本文中,我们将深入探讨操作系统如何进行磁盘管理,并基于提供的"DiskManage"压缩包文件,讨论其中可能包含的相关代码和设计。 1. **磁盘管理的基本概念** - 磁盘分区:为了更好地组织和管理磁盘空间,操作系统...
在深入探讨Linux用户管理之前,我们先明确一点,即Linux作为一款功能强大且安全的多用户操作系统,用户管理是其核心功能之一。用户与组的管理不仅是确保系统安全的关键,也是实现资源高效利用的基础。本文将围绕...
下面将详细讨论用户管理server层的关键知识点及其在实际开发中的应用。 首先,用户管理server层是整个用户管理系统的核心,它的主要职责包括: 1. **用户注册与认证**:这是用户管理的基础,server层需要接收并...
- 验证码(checkno):可能用于验证操作的合法性。 5. **公告管理表(TAB_NOTICEMANAGE)**:管理论坛的公告: - 公告ID(noticeid):公告的唯一标识,自增。 - 公告时间(noticetime):公告发布的日期。 - 公告内容...
网站后台管理操作手册样本主要涵盖了如何有效地管理网站的各类信息,包括内容发布、修改和删除。以下是手册中涉及的关键知识点: 1. **进入后台**:首先,管理员需要通过登录界面进入后台首页面,通常需要输入...
这包括单元测试、集成测试和系统测试,以验证用户管理的所有功能是否按预期工作,如添加、修改和删除操作的正确性,以及权限分配的有效性。 6. **教学方法**: - 使用项目教学法、分组讨论法和理论实践一体化的...
9. 磁盘管理:虽然在课程设计中可能不会深入到磁盘物理层面,但理解文件如何在磁盘上分配空间是重要的,这涉及到簇、扇区和磁道的概念。 10. 性能优化:通过对文件和目录的操作进行适当的设计,如采用哈希表或B树...
- 会员管理系统可能会涉及多步骤的操作,如充值或购买会员卡,这需要事务的支持来保证数据的一致性。 - 事务具有ACID(原子性、一致性、隔离性和持久性)特性,确保操作的完整性。 9. **备份与恢复**: - 定期...
本章主要讨论的是作业管理和用户接口,这是操作系统的重要功能之一,旨在提高用户与计算机系统的沟通效率。 首先,用户与操作系统之间的接口是操作系统设计的关键,分为命令接口和程序接口。命令接口是用户直接通过...
论坛管理系统是互联网上常见的一种互动交流平台,它允许用户发表观点、进行讨论和分享信息。在设计这样的系统时,数据库的构建是核心部分,确保数据的高效存储、检索和管理。本篇文档将深入探讨如何使用SQL Server或...
【SQL + JSP 简单论坛系统】是一个基于JSP技术开发的在线讨论平台,主要涉及用户管理和帖子管理两大核心功能。系统采用三级管理模式,包括普通用户、版主和论坛管理员,各等级用户拥有不同的操作权限。 1. **用户...
综上所述,这个实验提供了丰富的数据库管理和操作经验,不仅涵盖基本的数据库创建和表的建立,还深入到数据完整性的实现,以及数据的增、删、改操作,是学习和理解数据库操作的重要实践。通过这些操作,我们可以更好...
操作系统中的文件管理是计算机系统的重要组成部分,...总之,文件管理是操作系统中的关键技术,它关系到用户对数据的访问效率和安全性。通过对文件系统的深入理解和实践,我们可以更好地利用计算机资源,提高工作效率。
这些功能一般由管理员后台实现,提供对所有用户数据的控制和监控,确保网站的正常运营和用户行为的合规性。 在实际开发中,为了提高安全性,还会考虑使用CSRF(跨站请求伪造)令牌来保护敏感操作,使用HTTPS协议...
在OpenEulr操作系统中,用户和权限管理是系统安全性和资源访问控制的关键部分。学习这一主题,您将深入理解如何有效地管理用户、用户组以及文件和目录的访问权限,从而确保系统的稳定运行和数据安全。 首先,让我们...
《学生信息管理系统设计方案》不仅详细阐述了系统的设计思路与功能模块,还深入讨论了数据库设计的重要性。该系统通过自动化信息管理流程,显著提升了学生信息处理的效率和准确性,有助于学校管理者做出更加精准的...
在Linux操作系统中,用户和组的管理是系统安全和权限控制的核心部分。本文将深入探讨这一主题,重点关注《Linux用户和组管理问与答》中提及的知识点。 首先,我们讨论的是 `/etc/passwd` 文件,这是一个至关重要的...
1. 用户管理:用户注册、登录、个人信息管理等功能,确保用户身份的安全性和唯一性。注册过程可能涉及邮箱验证或手机验证码,以增强账户安全性。 2. 论坛版块:不同的主题分类,如技术讨论、生活分享等,方便用户按...