Hibernate和Spring的决裂以及Spring和EJB3之争

有！。你需要采用ejb3。 :-)

没记错的话需要使用spring的transaction proxy。

如果既可以不需要template，也不需要多谢try/catch，是不是更好？

The main issue with such DAOs is that they always get a new PersistenceManager from the factory. To still access a Spring-managed transactional PersistenceManager, consider defining a TransactionAwarePersistenceManagerFactoryProxy (as included in Spring) in front of your target PersistenceManagerFactory, passing the proxy into your DAOs.

<beans>
  ...

  <bean id="myPmfProxy"
      class="org.springframework.orm.jdo.TransactionAwarePersistenceManagerFactoryProxy">
    <property name="targetPersistenceManagerFactory" ref="myPmf"/>
  </bean>

是的， 如果用H3.0.1以上版本的话，只用spring注入SessionFactory，然后改用getCurrentSession方法：

public class ProductDaoImpl implements ProductDao {
    private SessionFactory sessionFactory;

    public void setSessionFactory(SessionFactory sessionFactory); {
        this.sessionFactory = sessionFactory;
    }

    public Collection loadProductsByCategory(String category); {
        return this.sessionFactory.getCurrentSession();
                .createQuery("from test.Product product where product.category=?");
                .setParameter(0, category);
                .list();;
    }
}

在目前的spring版本里面, jdo/toplink/ibatis2/h3，都可以不用template方式，而改用各个orm的native api去做，唯一的区别就是：有些orm用的是checked exception，需要多写try/catch

这样的话，session是从orm这层直接获取的，那如何通过AOP的方式来控制事务？

The main advantage of this DAO style is that it depends on Hibernate API only; no import of any Spring class is required. This is of course appealing from a non-invasiveness perspective, and might feel more natural to Hibernate developers.

However, the DAO throws plain HibernateException (which is unchecked, so does not have to be declared or caught), which means that callers can only treat exceptions as generally fatal - unless they want to depend on Hibernate's own exception hierarchy. Catching specific causes such as an optimistic locking failure is not possible without tying the caller to the implementation strategy. This tradeoff might be acceptable to applications that are strongly Hibernate-based and/or do not need any special exception treatment.

A further disadvantage of that DAO style is that Hibernate's getCurrentSession() feature just works within JTA transactions. It does not work with any other transaction strategy out-of-the-box, in particular not with local Hibernate transactions.

Fortunately, Spring's LocalSessionFactoryBean supports Hibernate's SessionFactory.getCurrentSession() method for any Spring transaction strategy, returning the current Spring-managed transactional Session even with HibernateTransactionManager. Of course, the standard behavior of that method remains: returning the current Session associated with the ongoing JTA transaction, if any (no matter whether driven by Spring's JtaTransactionManager, by EJB CMT, or by plain JTA).

In summary: DAOs can be implemented based on plain Hibernate3 API, while still being able to participate in Spring-managed transactions. This might in particular appeal to people already familar with Hibernate, feeling more natural to them. However, such DAOs will throw plain HibernateException; conversion to Spring's DataAccessException would have to happen explicitly (if desired).

These are the limitations


We have only sparsely tested the embedded stack. Consider it an alpha release
The Embedded stack is based off of CVS HEAD, not JBoss 4.0.x. Future versions will be based off of 4.0.x code.
We have done no pruning of jar files so the distribution disc size is a little large.
Documentation is sparse. Hopefully the tutorial examples are enough to get started.
EJB/JBoss Security is not available yet.
XA Connection pool is not available yet.
When embedding into Tomcat, you still require a JBoss specific JNDI implementation. Tomcat's JNDI is read-only.
You still must use the JBoss transaction manager even when embedding in another app server vendor. This will be remedied in the future when the JBoss AOP/Microcontainer integration is complete.
Distributed remote communication is not supported yet.
EJB Timer service not supported
Even though @Remote interfaces are local, you can only communicate through local connections.
You cannot access JMS remotely. Only locally. Thus, you have to lookup the "java:/ConnectionFactory".
JNDI is not available remotely

Charlesxp的产品何时能成熟？

扩大投资，增加开发人员数量...

I wish I could.但我也不可以让我老婆饿肚子咯。 VC喜欢投什么，大家也看得见。