我觉得关于“粗粒度”问题在使用aop的框架中不存在。
因为可以把需要事务处理的方法定义成一个aspect，这样结构更加清楚。

不好意思，没有仔细看版主的文章。//版主和俺是一条心啊，hoho

我觉得是不是Spring包括的面比较广，故就没有重点，我觉得要使用他无法也就用一个Bean Factory还可以，除了这个好像别的framework比他做得强。刚看spring.

>Bean Factory
是的，Bean Factory类似微容器，有生命周期，这样，你可以把你的javaBeans装进去带了跑，运行于各种JAVA平台中，我自己是使用piccontainer实现这个的。

看了老半天也看不出这种framework怎么池化对象？

看了《探讨Spring框架使用真相》，对SPRING的事务作了测试，在不使用EJB容器事务(CMT)，在service中使用SPRING的JTA的事务机制。可以做到service中两个DAO的事务同时回滚。经过这两天的调试，现在spring与EJB的关系已经理顺，可以实现真正的分布式EJB。

spring是不错,关注中.

高级DAO编程，讲解了JDBC事务管理和JTA事务管理
看了就了解了编程式事务的原理和实践。

EJB是申明式事务管理。基于配置，

所以Spring和EJB联合没有必要。
Springwithout EJB才是从他的角度的结果。

还有一点：技术本无高下之分，只有适用之分。

我个人觉得Spring的意在建立一种依赖注入DI（反向控制IOC）和面向接口一种编码规范, 他和EJB容器的确用的技术和方法是一样的，但是因为二者的市场和开发需求定位不一样，导致他们在开发的时候对接口的和配置的不一一样，那么对于Spring的结合EJB的容器进行协调必然导致接口的衔接问题.

Spring框架使用的真相就是不用ejb，without ejb里面表达的也是这个意思。
对于事务粒度，spring是可以控制的,需要设置回滚的条件：
public void updateUser(){
　　　　updateTabel1();//更新table1
　　　　updateTable2(); //更新table2
　　}
如果发生异常指定的异常,对table1,table2的操作都将回滚!

我想你证明了原文中关于EJB把真正的逻辑 "委托" 给受Spring管理的POJO 后失去transaction 力度控制的判断是不正确的. 作者应该修改原文这一部分的论述。

使用 Spring 提供的 session bean 的 基类 以后, 用户大致会 不使用 EJB 容器提供的 Transaction 控制 而改用 Spring 的Transaction管理。 这里，Sessionbean 基本上变成了 Spring 管理的业务逻辑的 ejb protocol 的 adapter。

这样做是有意义的。 假如你有一个“老式的” 基于ejb 的应用， 已可以用这种方式逐步地使用Spring提供的方便功能 实现新的业务逻辑或者改造一些老的业务功能。当然， clustering 也许是另外一个给 Sping 穿上 ＥＪＢ外衣的原因。即使如此， Spring 对 scalability 的 假设是：

一个好的 web container 能为 web applications提供有力的 failover 和clustering 的支持。

这样 Sping 就把 性能的扩展性任务推给了 web container。

bran在这方面思考比较深入，大部分观点和我比较相似。有两点值得商酌：

1.关于事务粒度控制方面，目前Spring版本的事务支持粒度确实不是丰富细致，我想这个问题以后会得到提升，特别是分布式环境下的事务回滚，这恐怕Spring在短期内难以做到的，所以我称其为粒度事务控制不是很到位，目前来说应该是不偏激的。

2.Sping 就把 性能的扩展性任务推给了 web container，那么我们就要求有一个好的Web容器提供Cluster支持，但是遗憾的是，目前J2EE标准中并没有和涉及Web容器的任何Cluster定义或接口，所以造成有的Web容器提供Cluster，如tomcat有一些，jetty比较好，大部分商业化产品如Weblogic则没有，它们把Cluster集中在EJB层了。

所以，现在就开始混乱了，有可能使得WEB应用程序和具体Web容器绑定，如Jetty，可移植性和兼容性的恶梦又开始在Web层上演。

大量纯Web层沉淀系统太多了，而J2EE标准又没有给它们指明可拓展性的出路，最后，只能向Tangosol这样收费的分布式缓存产品交费了。

这就是Web层系统性能提升的出路吗？
这个tapestry + spring + hibernate开源先驱也在力度引导我们走入这个方向，有些可悲：


https://betterpetshop.dev.java.net/

作者自称自己是Cluster的，仔细查看，就是采用Tangosol实现，这点是在其http://217.164.144.19:7001/ 演示地址说明的，不过我刚才没有能够访问到http://217.164.144.19:7001/这个Cluster后强大的性能能力，估计已经Down机很长时间了。

我会辩解说, ejb 有什么样的粒度， spring 也能提供。

在 jpetstore 示范程序里面， 两个 DAO 对象可以使用不同的datasource， 也就是这样：


	<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
		<property name="jndiName"><value>java:comp/env/jdbc/jpetstore</value></property>
	</bean>

	<!-- Additional JNDI DataSource for J2EE environments -->
	<!-- Refers to the order database, containing order data -->
	<!-- (see dataAccessContext-local.xml for an alternative) -->
	<bean id="orderDataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
		<property name="jndiName"><value>java:comp/env/jdbc/jpetstore-order</value></property>
	</bean>

	<bean id="itemDao" class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapItemDao">
		<property name="dataSource"><ref local="dataSource"/></property>
		<property name="sqlMap"><ref local="sqlMap"/></property>
	</bean>

	<!-- Refers to the order database here -->
	<!-- (see dataAccessContext-local.xml for an alternative) -->
	<bean id="orderDao" class="org.springframework.samples.jpetstore.dao.ibatis.SqlMapOrderDao">
		<property name="dataSource"><ref local="orderDataSource"/></property>
		<property name="sqlMap"><ref local="sqlMap"/></property>
		<property name="sequenceDao"><ref local="sequenceDao"/></property>
	</bean>

这里面 itemDao 和orderDao 使用不同的 datasource, 这两个datasource 都是由 j2ee 容器配置在 JNDI 中的.

在 petStoreImpl中 有这样一个方法



	public void insertOrder(Order order) {
		this.orderDao.insertOrder(order);
		this.itemDao.updateQuantity(order);
	}

现在我们把perStoreImpl 放到一个 SLSB 中， 有三种管理 transaction 的方法：

- CMT (Container Managed Transactions) wrapping the EJB, delegating to a POJO object wrapped with Spring Transactions.
- CMT wrapping the EJB, delegating to a POJO object not wapped with any Spring transactions.
- NO CMT wrapping the EJB, delegating to a POJO object wrapped with Spring TX.

这三种方法都能达到相同的效果: 完成一个跨越数据库的transaction. 实际上Spring 的作者们似乎更倾向于最后一种方案, 也就是不用 CMT 而全部依靠Spring.

在处理分布交易方面, Spring 似乎并无先天局限性. 放在高端 j2ee 容器中, spring可以使用 容器提供的各种分布式资源, 并正确地完成交易,独立自主地, 或者参与到 CMT 中.

下页