Make CallContextCatalogFactory request-scoped #2972
Conversation
note the only non-test usage spot is `IcebergCatalogHandler#initializeCatalog` and `IcebergCatalogHandler` is getting created by `IcebergCatalogAdapter` which is already `@RequestScoped`.
XN137
force-pushed
the
request-scoped-CallContextCatalogFactory
branch
from
b8e0012 to
4a2835b
Compare
There was a problem hiding this comment.
These changes LGTM 👍 Thanks, @XN137 !
All changes are contained within the runtime/service module, so there's no impact to polaris-core users downstream.
Making the factory request-scoped improves alignment among service classes and reduces the dependency on realm-based caching in metaStoreManagerFactory.getOrCreateMetaStoreManager(RealmContext).
github-project-automation
bot
moved this from PRs In Progress
to Ready to merge
in Basic Kanban Board
| import org.slf4j.LoggerFactory; | ||
|
|
||
| @ApplicationScoped | ||
| @RequestScoped |
There was a problem hiding this comment.
A general remark: just because a CDI bean is being injected request-scoped beans, doesn't mean the bean itself must switch to request scope.
All is needed is that the request scope must be active when any of the injected request-scoped beans is accessed.
Here for instance, this is the case, so keeping @ApplicationScoped doesn't hurt. I tried, and all tests passed.
Keeping application scope whenever possible reduces the number of proxies created for each request.
There was a problem hiding this comment.
i thought we generally wanted to avoid injecting request-scoped beans into application-scoped beans...
so whats the guiding principle when something should be application or request scoped then for you?
i thought since the PolarisPrincipal is being derived from SecurityContext and is now a ctor parameter, we should mark this class as request-scoped, to make clear this factory is only usable while handling a request.
and as stated in the PR description afaict the factory is only ever injected into IcebergCatalogAdapter which is marked as request-scoped already.
There was a problem hiding this comment.
Injecting request-scoped PolarisPrincipal into an @ApplicationScoped bean will work in Quarkus, but the injected object will be a proxy, switching to the active context in runtime.
From my POV making this bean @RequestScoped is nicer because it makes bean grouping more explicit and this bean does not have to keep any global state.
github-project-automation
bot
moved this from Ready to merge
to Done
in Basic Kanban Board
* chore(enhancement): rename python package to apache-polaris (apache#2812) - reorganize python package catalogs - union all submodules (cli, polaris) under apache_polaris module - put polaris generated context into apache_polaris/sdk - make apache_polaris as a main module * Update dependency pip-licenses-cli to v3.0.1 (apache#2996) * docs: Add quickstart documentation (apache#2976) * Add quickstart documentation targeting CLI convenience Co-authored-by: Alexandre Dutra <adutra@apache.org> * Update dependency io.quarkus to v3.29.1 (apache#2985) * Add getting started docs for Apache Ozone (apache#2989) Closes apache#2207 * Add note on appendConfigOption Helm template explaining its logic (apache#2995) This has come up a few times as the logic is a bit surprising for people familiar with Helm templates. * fix(deps): update dependency io.micrometer:micrometer-bom to v1.16.0 (apache#3001) * chore(deps): update quay.io/keycloak/keycloak docker tag to v26.4.4 (apache#3002) * fix(deps): update dependency io.smallrye.common:smallrye-common-annotation to v2.14.0 (apache#3003) * NoSQL: Add Mongo database backend (apache#2992) * NoSQL: Add Mongo database backend This change adds the MongoDB specific `MongoDbBackend` implementation. Test cases inherited from the database agnostic `AbstractPersistenceTests` for `Backend` implementations, running against a testcontainer running Mongo. * bump mongo container version * NoSQL: "standalone" `Persistence` configuration helper (apache#2993) This change adds a utility module used in follow-up PRs like JMH based micro-benchmarks and correctness-tests, running as "standalone" JVMs providing flexible configurability via explict smallrye-config usage. This allows running JMH and correctness tests against various deployment scenarios, even multi-node database backends without having to spin up a full server instance. In other words: targeted benchmarking and testing eliminating side effects potentially induced by other components. * NoSQL: Docker-compose example for customized testing (apache#2994) * NoSQL: Docker-compose example for customized testing Upcoming PRs bring JMH based benchmarking and correctness testing. This change adds a docker-compose on how to spin up a 3 node MongoDB instance useable for the mentioned benchmarks/tests. * fix(deps): update dependency com.google.errorprone:error_prone_core to v2.44.0 (apache#3004) * Make CallContextCatalogFactory request-scoped (apache#2972) note the only non-test usage spot is `IcebergCatalogHandler#initializeCatalog` and `IcebergCatalogHandler` is getting created by `IcebergCatalogAdapter` which is already `@RequestScoped`. * Last merged commit 6546689 --------- Co-authored-by: Artur Rakhmatulin <artur.rakhmatulin@gmail.com> Co-authored-by: Mend Renovate <bot@renovateapp.com> Co-authored-by: Adam Christian <105929021+adam-christian-software@users.noreply.github.com> Co-authored-by: Alexandre Dutra <adutra@apache.org> Co-authored-by: Dmitri Bourlatchkov <dmitri.bourlatchkov@gmail.com> Co-authored-by: Christopher Lambert <xn137@gmx.de>
4 participants
note the only non-test usage spot is
IcebergCatalogHandler#initializeCatalogand
IcebergCatalogHandleris getting created byIcebergCatalogAdapterwhich is already
@RequestScoped.