请教一个在完整提交前临时保存的问题(事务)!!

是这样的 比方说人员的添加页面 对应一个用户可以有多种职务或角色 那么在保存用户信息前 必须要为其至少赋予一个职务和一个角色 这样的话 会在用户信息保存前 先产生职务列表和 角色列表 在数据库设计中 人员和职务角色是通过用户ID关联的 在未保存人员信息前 已选择的职务和角色可以删除

我们现在的做法是 将用户设置一个扩展对象 里面添加了角色列表和职务列表 然后在session中存取职务和角色信息 用户信息保存时 从session中取出职务列表和角色列表 同时结合用户基本信息在一个事务中操作 操作完成后清空session 问题可以解决

我想请问类似这样的问题 除了使用session或xml临时存取 有没有更好的解决办法 望答复 谢谢!・

不知你这个session是否是httpsession?
如果是,就产生一个问题,你的保存在session中这些功能其实是业务功能,业务功能应该在业务层实现,而你在表现层实现,违反了多层划分原则,这是设计基本原则。

所以,你必须在业务层使用Session,而目前支持业务层Session的有EJB和JdonFramework,Spring则不支持。

采取EJB的有态Bean,当你的用户量大时,session会占据很多内存,甚至撑死你的机器,而有态Bean会自动钝化或激活,保证信息不丢失。

放在sessionBean 和 HttpSession没有什么本质的区别 用户量不会特别大 主要是系统管理里的东西 使用频率比较少 使用完之后从session里面就拿掉了

就是想知道有什么更好的解决办法去解决这个问题

>放在sessionBean 和 HttpSession没有什么本质的区别
错误,有本质区别,违反多层架构设计原则,使用Java的根本目的是什么?不是B/S结构,而是多层架构,可以实现多层解耦,如果你的软件层次混乱,可维护性和可拓展性哪里有?这就是本质区别。

>就是想知道有什么更好的解决办法去解决这个问题
什么是更好?更好就是追求设计,那些参考第一条。将业务过程放在业务层是更好的解决办法。

如果违背设计原则(这是领域建模DDD反复强调的设计原则)不算本质区别,那么在你的概念中我不知本质区别是什么?

使用EJB的有态Bean的session 同步机制Session Sychronization可以确保将缓存数据保存到数据库,并且通过有态Bean中提供的几个方法可以确定顺序时间:

afterBegin():事务刚刚开始之时,这时你可以将数据库数据读入缓存中。
beforeCompletion():就在事务已经结束之前激活,可以将数据写入数据库了。
afterCompletion():事务已经完全结束后,做一些事务完成或失败的复位工作。

板桥大哥,我想问你一下,JDONFRAMEWORK如何实现业务层的Session,能给个具体的事例吗?谢谢

可以用,基于cookie的session实现!
这个可以解决一些服务器保存session的问题!
且适用分布式群集环境!

请问Banq大哥,你是怎么实现业务Seesion的呢,在那里有讲述,能否透露一下?

不能在数据库中专门建立一个保存这种临时数据的表吗?

>怎么实现业务Seesion的
我是使用JdonFramework来实现Session的,如果采取EJB,使用有态Bean

>不能在数据库中专门建立一个保存这种临时数据的表吗?
不能,这就是典型以数据库为中心的编程思想,什么事情都靠数据库,最后负载压在数据库上,java应用服务器的分布式集群方案就毫无用武之地了,而且:数据库的集群能力有限,只能靠提高单机配置,走上集中式主机传统路子。

> >不能在数据库中专门建立一个保存这种临时数据的表吗?
> 不能,这就是典型以数据库为中心的编程思想,什么事情都靠
> 菘猓詈蟾涸匮乖谑菘馍希java应用服务器的分布式集?> 方案就毫无用武之地了,而且:数据库的集群能力有限,只能
> 刻岣叩セ渲茫呱霞惺街骰陈纷印?


如果需要记录每一步的操作,那么记录到数据库还是有必要的,可以形成一条完整的链条。如在销售系统中,经常需要记录临时信息

不是完全赞同 板桥 大哥的观点。分层说比较赞同,但是有态Bean我不觉得是万能的。……

这么说是看了《简单问题?》等等贴子你的观点,有些东西到用起来并不是那么神奇,反倒成为枷锁。

加个session很难么?

在action之前,先截取request对象(比如可用filter),放到自己的application域中,然后想乍包装就乍包装.
随便猜的一种做法,只是这种东西俺认为实现起来应该没什么.