search

ebean-orm / ebean

Ebean ORM
https://ebean.io
Apache License 2.0
1.47k stars 261 forks source link

In WebFlux， How to context transmission #3303

Closed PassXml closed 9 months ago

PassXml commented 9 months ago

My apologies for not adhering to the prescribed format for raising issues, as I deem this discussion to be more of an exploration, devoid of coding elements.

Within the domain of Spring WebFlux or other analogous reactive frameworks that employ a multithreaded paradigm, information propagation is accomplished via a context-oriented mechanism.

Currently, Ebean's interface for tenant information extraction is inherently blocking, yet this is incongruous with WebFlux's default scheduler which forbids blocking operations for context retrieval.

I observed that the execution thread for Ebean's queries, modifications, and deletions is the originating thread, thus I applied ThreadLocal for transmission, a method somewhat imbued with a touch of magic.

Additionally, the prevalence of reactive scenarios is likely to surge.

Thus, could there exist a more sophisticated mechanism for context transmission?

rbygrave commented 9 months ago

reactive scenarios is likely to surge

Maybe but with Java 21 released with Virtual Threads (Loom) I don't believe "reactive scenarios will surge".

For myself I've had a long look at reactive database drivers (vs JDBC) and I'm absolutely comfortable and confident sticking to JDBC. I realise you didn't ask that question but this is the more fundamental question for an ORM and I want to be clear that for ebean there is no interest in pursuing reactive drivers.

ThreadLocal for transmission, a method somewhat imbued with a touch of magic

This has been the common mechanism used for propagating transactions (eg. @Transactional) and also commonly propagating user context information (principal, roles etc) for a very long time.

Going forward there JEP 453 Structural Concurrency - this will bring in StructuredTaskScope with the intention that this will replace so use cases which today use ThreadLocal.

could there exist a more sophisticated mechanism

There is no plan for anything extra or any change for propagating tenant information.

PassXml commented 9 months ago

Perhaps it's an overthought on my part, as I pondered whether ORM should operate akin to thread scheduling, which would indeed render ThreadLocal unreliable. However, as it stands, ThreadLocal seems to function as a sound mechanism - merely a case of me borrowing trouble. JEP 453 Structural Concurrency appears to be a promising concept, and I shall dutifully keep abreast of its evolution.