SSH架构
业务原型：
在一级事务T1中查询出id为12345的持久化对象A1，并修改了A1的memo属性，T1提交之前调用了一个方法M，M中使用PROPAGATION_REQUIRES_NEW开启了一个新的事务T2，在T2中又查询出id为12345的持久化对象A2，修改了A2的memo属性，在T2提交后，A2的memo变化被同步到数据库中，但是在T1提交后A1所做的修改却没有同步到数据库中，而且也没有报数据版本异常。
通过调试发现：A1和A2虽然指向数据库中的同一行，但是是不同的对象实例
疑问：
1、Hibernate的持久化对象只应该在系统中存在一份，为什么这儿会出现A1、A2两个持久化对象呢？
2、为什么T1没有做任何提交动作（因为如果提交了的话肯定会报数据版本不同的异常）
源码分析：
在TransactionTemplate的<T> T execute(TransactionCallback<T> action)中会通过TransactionManager的getTransaction方法来取得TransactionStatus
1、取得当前线程所关联的SessionHolder
2、若存在SessionHolder并且开启了事务(this.sessionHolder != null && this.sessionHolder.getTransaction() != null)，而且当前的的传播行为为PROPAGATION_REQUIRES_NEW
3、挂起当前线程绑定的事务及其事务同步器，取消当前线程和当前session和connection的绑定，并保存所有的挂起信息以供恢复
4、创建新的session，并开启新的事务
5、执行TransactionTemplate的TransactionCallback回调
6、在新事务提交后，会恢复上个事务的所有信息和执行
答1：可以看出，使用PROPAGATION_REQUIRES_NEW时，Spring会在一个请求线程中生成另一个独立的Hibernate的session和事务，所以会存在两份持久化对象
如果将事务传播方式改为PROPAGATION_NESTED，Spring会使用之前session和事务，并通过事务的SavePoint来实现嵌套事务。
另外，在Hibernate的reference里面有句话：A Hibernate Session is a transaction-level cache of persistent data. 可以理解为在一个session中只能有一个关联的事务（嵌套事务只是父事务的savepoint，不能算作一个事务），一旦这个事务结束将会移除这个关联关系（JDBCContext.afterTransactionCompletion方法中），并且一个session中开启的多个事务可以共享缓存
答2：怀疑在T1检查脏数据时认为没有脏数据，所以没有做任何提交
答2：跟踪发现确实报了乐观锁异常，日志打到另外的地方去了