“Hibernate與JDBC(iBATIS)??都使用 DataSourceTransactionManager 同樣可以保證事務
原理就是保證了 connection 的唯一性。
jdbc我是調spring的jdbcTemplate來操作，
經過測試。在同一個數據源的情況下直接使用Hibernate的TxManager可以同步事務，問題解決。
”
Rod Johnson的話：
引用
It is possible--and sometimes useful--to have coordinated transactions for both. Your JDBC transactions will be managed by the HibernateTransactionManager if you work with the same JDBC DataSource in the same transaction. That is, create the SessionFactory using Spring's SessionFactoryBean using the same DataSource that your JdbcTemplates use.

The only issue to watch, of course, is that you may be invalidating your Hibernate cache by JDBC changes. Generally I find it best to use JDBC to update only tables that don't have Hibernate mappings.

Juergen Hoeller的話：
引用
As Rod said, simply keep using HibernateTransactionManager, which auto-detects the DataSource used by Hibernate and seamlessly exposes Hibernate transactions as JDBC transactions for that DataSource. JDBC code that accesses the same DataSource via Spring will automatically participate in such transactions.

Note that you must specify the DataSource for Hibernate via LocalSessionFactoryBean's "dataSource" property to allow HibernateTransactionManager to auto-detect it. Alternatively, you can explicitly pass the DataSource to HibernateTransactionManager's "dataSource" property.
http://www.fireflow.org/redirect.php?tid=498

Rod Johnson在spring 論壇中有一句話很好的總結了如何在測試中處理hibernate緩存:
Remember that you can clear the Hibernate session, removing objects already associated with it. This is often necessary before requerying in tests, and solves most (if not all) problems.
I typically use JDBC for verification. The pattern is
- do Hibernate operation
- flush Hibernate session
- issue JDBC query to verify results
That way I'm verifying what Hibernate did to the database in the same transaction.