Deprecate ChainedTransactionManager [DATACMNS-1817]

[spring-projects-issues]

Mark Paluch opened DATACMNS-1817 and commented

ChainedTransactionManager is the primary class in org.springframework.data.transaction that is used for multi-transactionmanager arrangements. It is useful to coordinate transactions across multiple resources especially when one transaction manager is a Spring one and the other is a foreign one.

Over time, we found that we're basically emulating distributed transactions on a best-effort basis with known gaps. These gaps lead to inconsistencies or unexpected behavior during rollbacks. Part of the problem is that resource/synchronization storage is a singleton ThreadLocal. Using two transaction managers based on AbstractPlatformTransactionManager causes the first transaction manager to handle all synchronizations regardless of their resource origin (primary and secondary transactional resources). If the second transaction manager commit fails, then already all synchronizations are processed and there's no way to recover.

Therefore, we're going to deprecate ChainedTransactionManager and the entire org.springframework.data.transaction that hosts support classes for multi-transactions

---

Issue Links:

• DATACMNS-370 ChainedTransactionManager should only control transaction synchronization if all delegate transaction managers are set to NOT control synchronization
  ("supersedes")
• DATACMNS-1221 ChainedTransactionManager - Issue with HibernateTransactionManager and KafkaTransactionManager
  ("supersedes")
• DATACMNS-1253 ChainedTransactionManager and Ignite SpringTransactionManager
  ("supersedes")
• DATACMNS-1314 ChainedTransactionManager does not handle transaction sychroriazation correctly
  ("supersedes")
• DATACMNS-1789 Reactive ChainedTransactionManager
  ("supersedes")
• DATACMNS-1604 Support 'afterAllCommit' in ChainedTransactionManager
  ("supersedes")

[spring-projects-issues]

s-mop commented

Yes, it is a problem when commit fails after the first commit is done, but
Is there any suggested replacement workaround or other best practice to handle with multi-transaction scenario? for example different datasource or different data storages.Mark Paluch

[spring-projects-issues]

Mark Paluch commented

From what I see the issue is rooted in how Spring's Transaction Manager works with synchronization. The initial assumption is, there's a single transaction manager that takes care of resources and synchronizations. Hence, all integrations interact with TransactionSynchronizationManager which is backed by singleton ThreadLocals. Since it never was required to qualify synchronizations and resources with an owing transaction manager, all of these are mixed and we're not able to sort out transactional resources.

Typically, transactional integrations bind their DataSource (or other resources) to the transaction and do not care about the transaction manager. Looking at e.g. DataSourceTransactionManager, the transaction manager is aware of the DataSource while e.g. JdbcTemplate is only aware of the DataSource and not the transaction manager. Going further, DataSourceUtils.getConnecion(…) binds a ConnectionSynchronization to the transaction without the chance to know for which transaction manager the synchronization should apply

[spring-projects-issues]

Kaushik commented

Yes. I am facing this issue in our project. But we use this heavily in our projects.

Just a quick search of public gihub repositories that use this class - https://github.com/search?q=%22org.springframework.data.transaction.ChainedTransactionManager%22&type=Code

Looking at the amount of usages, we need an alternate and much better approach to this

[OrangeDog]

So what should we do when we need to use multiple DataSources in a single @Transactional section? This was the simplest configuration when inconsistent rollbacks (i.e. one commits while another rolls-back) were not an issue. Can an example be provided?

[softwarebrahma]

So what should we do when we need to use multiple DataSources in a single @Transactional section? This was the simplest configuration when inconsistent rollbacks (i.e. one commits while another rolls-back) were not an issue. Can an example be provided?

+1 I am interested aswell.

[idkw]

I agree, deprecating stuff without providing a clear migration path (with examples before/after) is not cool