Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Deprecate ChainedTransactionManager [DATACMNS-1817]
See original GitHub issueMark 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”)
Issue Analytics
- State:
- Created 3 years ago
- Reactions:1
- Comments:11 (2 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
So what should we do when we need to use multiple
DataSources in a single@Transactionalsection? 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?I agree, deprecating stuff without providing a clear migration path (with examples before/after) is not cool