-
Notifications
You must be signed in to change notification settings - Fork 38k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add reactive transaction support SPI #22646
Conversation
@mp911de Thanks for turning it into a PR, looks like a fine start for integration with Just one immediate thing: Could you please move the |
This commit adds SPI interfaces to support reactive transactions through spring-tx with optional dependencies to Project Reactor and supportive implementations for TransactionalOperator and AbstractReactiveTransactionManager.
Resolved |
Running out of time for 5.2 M1, rather expectedly... Let's make this a 5.2 M2 topic, first thing once M1 is out. I hope that's also early enough for Spring Data's purposes. |
That should work for us. |
Includes general revision of reactive transaction sources. See gh-22646
This is in master now, including a first pass with a revision of mine that removes all legacy configuration options from A second pass is coming in just a bit, renaming some of the types in @mp911de Please wait for that renaming commit before integrating the Spring Data bits with it. |
I also consider renaming |
@mp911de Are you ok with the shortened type names suggested above? It's ready for committing from my side. |
Being at it, I also intend to drop |
Thanks a lot for merging this one. I'm fine with shorter names. I'm always torn having multiple types with the same name. Right now, when using multiple transactional resources, it's sufficient to keep a single transaction manager and additional resources can join by registering By removing |
So who would use |
Hmm it seems that |
Introduces TransactionExecution base interface for TransactionStatus as well as ReactiveTransaction. Renames getTransaction method to getReactiveTransaction, allowing for combined implementations of PlatformTransactionManager and ReactiveTransactionManager. See gh-22646
It would make sense to keep |
The main reason for dropping it was the use of Thinking about it, we could even have a static defaults accessor on the |
That seems to work nicely with default methods on the |
I found two bugs during the integration in R2DBC and MongoDB ( |
Such a static unmodifiable TransactionDefinition with defaults can be used for getTransaction(null) calls, now also possible for getReactiveTransaction. Furthermore, it can be used for a simple TransactionalOperator.create(ReactiveTransactionManager) method without an internal dependency on the transaction.support package. See gh-22646
Alright, good to catch those bugs early enough still... The |
This commit adds SPI interfaces to support reactive transactions through spring-tx with optional dependencies to Project Reactor and supportive implementations for TransactionalOperator and AbstractReactiveTransactionManager.
See #22590 for more background. The implementation is mainly inspired by
spring-tx
leveraging Reactor's Subscriber Context.