怎样在一个spring+hibernate的框架下,使他能支持分布式服务器集群

数据库读写代码都是 hibernate 的 DAO
使用 org.springframework.orm.hibernate.HibernateTransactionManager
作为事务控制类,现在问题来了。我现在要组建一个多台服务器集群。
apache+多台tomcat 或者 apache+ 多台 jboss。做 load balance。

我现在数据库是一个mysql ,我不知道怎么把我的代码做到对数据库读写多台应用服务器能正确地读写。因为 spring hibernate 文档里我暂时没有找到 cluster 的内容。
我怎样修改代码,或者干脆放弃 spring hibernate 转投 EJB 2.0 ?
或者使用 JTA?但我不知道怎么使用?
望高手指教!

Spring+hibernate不支持集群,采取EJB调用Spring的方式。

板桥大哥谢谢回复

spring hibernate 就是说不支持分布式事务,均衡负载?但是我又看到spring只要调换一下本地JDBC连接换成JNDI数据库连接就可以了的说法,又看到在Action里面使用2段式JTA的提交方法就可以支持分布式事务的说法。我也有点糊涂了。

那我把JBDC 本地连接配置 换成 应用服务器支持的JNDI JDBC 配置这样是不是可以暂时解决分布式事务处理的问题呢?

如果 server1 server2 共同使用 一个 DB , 2个 app 的同样功能的jdbc 事务都需要在 table1 中插入数据 ,而且同时2台服务器有很多事务需要读取这张表的数据,这种情况下有什么简单的过渡方法?


更换数据源JNDI,只是利用了容器提供的数据库连接池等一些特性,包括跨数据库的一些事务机制。这适合一个app server + 多台db server。

你说的多台app server + 一台db server,目前除非自己手工做,只有使用EJB是最直接方便的办法。

Spring宣称它自己侵入性很少,所以,用反义词来说:就是它什么都不做,或者说,它没有什么东西,只有Ioc/AOP模式。

最近为了分布式应用以及均衡负载伤透了脑筋,也曾想过使用JTA 侵入 业务逻辑支持分布式,但是最终反复对比后,艰难取舍。觉得EJB 的整体解决了所有的功能,让开发人员从系统级的开发精力放到了业务逻辑的关注中来。spring+hibernate 的确是轻量级的,分布式自己去搞,花的精力要多的多。而且代码耦合性很高,业务逻辑和事务处理代码混杂在一起。分层次很伤脑筋。使用EJB2.0 的确会使开发大型系统在能力,安全,负载,事务,伸缩性,从体系上提高不止一个档次。spring +hibernate 轻量、快速、方便,有他的作用。EJB 架构 从开始就是从标准工业化布局,非常重量级。
真的考虑的很多很多。

最近在 EJB CMP 开发过程中 对于字段映射有很大的问题,我使用的数据库是mysql 开发工具为idea4.5 ,应用服务器为weblogic 8.1开发过程中总是遇到 字段映射不准确的信息,比较苦恼。
有关各字段参考资料可以那里可以找到?

还有有关采用 hibernate + slsb 方式开发的,声称可以使hibernate 通过session bean 实现分布式处理。这样的开发效果会比较好么?因为项目达到分布式支持的可用时间不多。面对如此多的理论讲法,好像都可以实现。有点忙乱。最重要的,采用混合式开发hibernate + session bean 没有最佳实践。也是比较困难的。技术架构太多,,技术联合使用,没有参考指导,的确非常困难。望了解当中细节的人能指明方向。

其实引入SLSB也比较简单,参见Spring手册中关于Spring在EJB中配置即可,然后,你做几个和你的business object同样接口的SLSB实现,每个方法委托给Spring中POJO的business object实现即可。

谢谢板桥大哥回复,我转换架构以后会整理一下经验,和其他的与我有过相同困惑的人交流交流。


I found you don't quiet understand what is cluster,distributed transaction .

cluster can be implented by application server(such as JBOSS, Weblogic..) ,as well as web server( such as tomcat5,resin).generally, it is has no realation to framework such spring,hibernate, struts...

distributed transaction is only used when you need to acess more than two different datasources in a transaction, which means it either be submitted successfully or roll back for all the datasource you accessed.

In your case, there is only one datasource, so no distributed transaction is needed. As for clustering, apache+tomcat4 or apache+jboss is eough. No EJB is required.

zrp 说的有道理,楼主所担心的cluster中的并发访问问题,与在一个application server中多用户同时操作时的情况是相似的。
我猜测可能问题的关键是 楼主之前的对并发问题的解决是局限在一个jvm中,而现在需要在多个jvm中保证并发正确。
如果是使用hibernate的话,它内置的乐观锁机制应该是解决这个问题的比较好的方案吧。

你到底是要cluster还是分布式?这是两个不同的概念。看你的需求,好象只是需要cluster吧?这样的话跟spring或则hibernate是无关的,只要应用容器或则服务器提供的功能就行了。当然设计的时候需要多考虑一些特殊的地方相对与单服务器应用,比如cache.如果是分布式应用,那ejb是目前综合因数最强的一种选择,当然你也可以选择基于rmi,web service,或则其它协议(比如cacho的hessian)的实现。而spring和hibernate和这些实现都不是什么对立的方面,完全可以嵌入到这些应用中。tmd,我记的好象前阵子谁也问了这个问题的。

to dabb :怎么能说使用spring+hibernate跟集群无关呢?选择了spring+hibernate这样轻量级的架构,目的就是摆脱使用ejb。可是,如果为了cluster再用ejb进行包装,不是非常奇怪么?直接使用ejb 算了。spring+hibernate进行集群问题在于hibernate的cache如何进行同步。如果真的需要应用层集群,那么还是要使用ejb的。

楼主的确是混淆了两阶段提交事务和应用层集群的概念了,完全是两回事情,没有应用集群的环境也可以使用两阶段提交的事务;而应用层集群的环境也可以不使用两阶段提交的事务。

使用spring+hibernate的话可以用路由器来实现集群嘛,
呵呵。

zrq老兄已经说得很清楚了。
我来拉杂一下。用weblogic来实现集群,性能是相当不错的,深有体会。jboss没用过,不便发表评论。tomcat嘛,来做集群就差了不少,最大优势当然是省钱了(想到weblogic的价格就肉疼)。所以,用什么完全看你的财力和要求了:)