Сложный программный контроль транзакций?

Question

Spring поддерживает программные транзакции, которые дают нам прекрасный контроль над управлением TX. Согласно Спринг документации, можно использовать программное управление TX по:
1. Используя TransactionTemplate весны:

transactionTemplate.execute(new TransactionCallbackWithoutResult() { 

protected void doInTransactionWithoutResult(TransactionStatus status) { 
    try { 
     updateOperation1(); 
     updateOperation2(); 
    } catch (SomeBusinessExeption ex) { 
     status.setRollbackOnly(); 
    } 
} }); 

2. Используя PlatformTransactionManager непосредственно (инъекционные реализацию PlatformTransactionManager в DAO):

DefaultTransactionDefinition def = new DefaultTransactionDefinition(); 
def.setName("SomeTxName"); 
def.setPropagationBehavior(TransactionDefinition.PROPAGATION_REQUIRED); 

//txManager is a reference to PlatformTransactionManager 
TransactionStatus status = txManager.getTransaction(def); 
try { 
    updateOperation1(); 
    updateOperation2(); 
} 
catch (MyException ex) { 
    txManager.rollback(status); 
    throw ex; 
} 
txManager.commit(status); 

для ради упрощения, скажем, мы имеем дело с операцией базы данных JDBC.

мне интересно, для каких-либо операций с базой данных произошло на updateOperation1(),updateOperation2() во втором фрагменте, либо он осуществляется с JDBCTemplate или JDBCDaoSupport, если нет, то операция фактически не выполняется в рамках какой-либо сделки, не так ли?

Мой анализ состоит в том, что, если мы не используем JDBCTemplate или JDBCDaoSupport, мы неизбежно создадим/заимствуем соединение из управления источниками данных. мы получаем соединение, конечно, не соединение, используемое PlatformTransactionManager, лежащее в основе управления транзакцией.

Я выкопал исходный код Spring и связанный с ним класс, что PlatformTransactionManager попытается получить соединение, содержащееся в ConnectionHolder, которое в свою очередь получено из TransactionSynchronizationManager. Я также нашел JDBCTemplate и JDBCDaoSupport, также попытаться получить соединение с аналогичной процедурой из TransactionSynchronizationManager.

Поскольку TransactionSynchronizationManager управляет много ресурсов, включая соединение в поток (в основном использует Threadlocal, чтобы обеспечить один поток получить свой собственный уникальный экземпляр управляемого ресурса)

Таким образом, я думаю, что соединение, полученное PlatformTransactionManager и JDBCTemplate или JDBCDaoSupport, является таким же, это может объяснить, как весенняя программная транзакция гарантирует, что updateOperation1(),updateOperation2() были защищены транзакцией.

Является ли мой анализ правильным? если это так, почему весенняя документация не подчеркнула этого оговорки?

Answer 1

Да, это правильно.

Любой код, который использует сырые Connection s должны получить их из DataSource специальным образом для того, чтобы принять участие в операциях, управляемых весной (12.3.8 DataSourceTransactionManager):

Код приложения требуется, чтобы получить соединение JDBC через DataSourceUtils .getConnection (DataSource) вместо стандартного DataSource.getConnection Java EE.

Другой вариант (если вы не можете изменить код, который вызывает getConnection()), чтобы обернуть DataSource с TransactionAwareDataSourceProxy.