Skip to content
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

Any plan to support R2DBC #3061

Open
eonezhang opened this issue Aug 25, 2020 · 3 comments
Open

Any plan to support R2DBC #3061

eonezhang opened this issue Aug 25, 2020 · 3 comments
Labels
type: feature Category issues or prs related to feature request.

Comments

@eonezhang
Copy link

eonezhang commented Aug 25, 2020

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

@slievrly slievrly added the type: feature Category issues or prs related to feature request. label Oct 9, 2020
@linghengqian
Copy link
Member

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.

@linghengqian
Copy link
Member

  • 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.

@linghengqian
Copy link
Member

  • 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 Subscriber payload or contextualize request reactive-streams/reactive-streams-jvm#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: feature Category issues or prs related to feature request.
Projects
None yet
Development

No branches or pull requests

3 participants