Open eonezhang opened 4 years ago
I'm trying to understand how much the "support" you expect has to do with Seata. After all, R2DBC would have allowed for the transaction model of the SAGA pattern.
I recommend closing this issue.
Because after R2DBC API 0.9.1.RELEASE, the R2DBC driver has a new level of support for transaction scalability. This issue is too old and doesn't give enough information and a reproducible example.
I don't think R2DBC should be discussed at this point in time. The core reason is that R2DBC does not restrict specific reactive API libraries, and draft issues such as https://github.com/reactive-streams/reactive-streams-jvm/issues/542 have not been closed, resulting in seata may need to adapt Project Reactor, RxJava, Smallrye Mutiny at the same time. This is too painful.
We take it for granted that adapting R2DBC means participating in the context propagation of R2DBC. In Spring, the Spring Team uses Reactor's subscriber context to associate context resources for out-of-band execution. On the seata side, ThreadLocal is usually used for this purpose. Each operation runs on its own connection. The problem is that Reactor's context is not part of the reactive streams standard, so seata can't really use it directly. This is also useful for injecting any kotlin coroutine context independent of Reactor. While there may be a "standard", everyone involved in the R2DBC ecosystem seems to have invented their own wheel in this area.
Why you need it?
Reactive programming becoming more and more pop at this moment, for database the community driven reactive database driver standard
r2dbc
is coming, so does this repo have any plan to support it?How it could be?
seata could support reactive way.
Other related information
http://r2dbc.io/ https://spring.io/projects/spring-data-r2dbc