第一个页面输入转出行信息--到ACTION,开启事务,修改记录,但不提交,该行记录被加上只读锁,别人只能查,不能改.第二个页面输入转入行信息--到action检查业务逻辑,正确后,进行转入,更新转入行记录,再提交.
这是一个完整的过程,你说的那个太........,现实不能那样做!
第一个页面输入转出行信息--到ACTION,开启事务,修改记录,但不提交,该行记录被加上只读锁,别人只能查,不能改.第二个页面输入转入行信息--到action检查业务逻辑,正确后,进行转入,更新转入行记录,再提交.
第一个页面输入转出行信息--到ACTION,开启事务,修改记录,但不提交,该行记录被加上只读锁,别人只能查,不能改.第二个页面输入转入行信息--到action检查业务逻辑,正确后,进行转入,更新转入行记录,再提交.
已， 听你这么一说， 你是面临着两个问题
1: 事务处理 2： 多用户并发
我仍然不是很明白为什么要在第一个Action中开启事务，我的建议是在第
一个Action中只读取数据，在界面上修改的数据保存在内存中，所以不要
开启事务。
还有一个就是楼主是不是把多用户并发的问题跟事务处理的问题混淆
了？
如果 DBMS 支持事务处理，它必须有某种途径来管理两个事务同时对一
个数据库进行操作时可能发生的冲突。你可以指定事务隔离级别为次高。
就是当某个用户读取数据时候，其他用户只能读取，不可修改。不过要在
性能方面牺牲。
关于事务隔离，请看
http://www.yesky.com/20020312/1601303_1.shtml
估计能找到想要的东西。
可能是由于能力不够，不能解决，不知道哪位能解答？
哎.........这个东西就是难搞
如果正如你所说"再单一功能被操作时,别的用户是禁止操作同一功能",我想可以设置一个机制而避免跨界面事务。
如：甲用户开始作指定操作的时候，设置一个全局（ServletContext）范围的Flg，并记录开始时间。这时若有乙用户也试图作该操作（系统可以根据全局Flg判断已经有人独暂了该操作），就显示提示页面，告诉乙用户已经有别的用户在作此操作，乙用户应该等一定时间以后再来试一试。
等甲用户完成了所有的操作（前几个画面中的操作信息记录在Session里面），在最后一个Action里面开启事务、作所有的SQL更新并提交事务、再释放全局Flg。
若甲用户迟迟不完成操作，在过了一定时间以后，也要把全局Flg释放，以接受别的用户的操作。
若采用跨界面事务，当甲用户在操作的时候，锁住数据库记录的话，先不说资源和性能问题，乙用户再请求的时候，他看到的应该是反应？是不是浏览器就那么缰掉了？直到甲用户的操作结束或HttpConnection Timeout...这也是要解决的问题。
因为不太清楚你们的业务CASE，可能又是我的胡思乱想。
若方便的话，你可以把具体的业务CASE列出来。
> 第一个页面输入转出行信息--到ACTION,开启事务,修改记录,但不提交,该行记录被加上只读锁,
> 别人只能查,不能改.第二个页面输入转入行信息--到action检查业务逻辑,正确后,进行转入,
> 更新转入行记录,再提交.
太笼统了，凭这句话还是感觉可以用xuesenlin和我以前所说的方法来解决。既然你“修改记录,但不提交”的话跟修改信息暂存到Session里面，最后一同更新有什么区别呢？只不过更新以前多加一次判断而以啊。
哎,,我晕啊,让我咋解释啊,咋还不明白,难道一个帐户只有转出的情况吗,加了锁,就是说不能再给它减,也不能给他加,你存在SESSION里哪能满足我的要求.
若采用跨界面事务，当甲用户在操作的时候，锁住数据库记录的话，先不说资源和性能问题，乙用户再请求的时候，他看到的应该是反应？是不是浏览器就那么缰掉了？直到甲用户的操作结束或HttpConnection Timeout...这也是要解决的问题。
另一个用户操作,我允许他查,不许他改,否则进入锁饥饿,总之是谁先提交,谁成功,明白了吗