yuqi1129 commented on PR #12423: URL: https://github.com/apache/gravitino/pull/12423#issuecomment-5265925323
> Thanks! I went through all ~16 other `ServiceLoader.load` sites. Grouped by whether the same refinement fits: > > **Init-once already (per-call caching adds nothing)** — scanned once at construction, a guarded singleton init, or a one-shot CLI command, not on a per-request path: > > * `LakehouseTableDelegatorFactory` — guarded static holder, memoized. > * `FileSystemUtils` / `BaseGVFSOperations` — loaded once into an `ImmutableMap` field at catalog-ops init / ctor. > * `KmsClientRegistry` — constructed once from the `GravitinoEnv` singleton. > * `SqlSessionFactoryHelper` — double-checked `init()`, baked into the singleton `SqlSessionFactory`. > * `WebIdentityTokenSources` — loaded once in the credential generator's `initialize`. > * optimizer `ProviderUtils` / `InstanceLoaderUtils` — resolved in optimizer object ctors / short-lived CLI commands. > > **Per-classloader by design (a static type→impl cache would be _wrong_)** — they pass an isolated or thread-context classloader so different catalogs/plugins resolve different impls: `CatalogManager`, `BaseAuthorization`, `AuxiliaryServiceManager`, `CredentialProviderFactory` (resolves against the catalog's isolated CL that `IsolatedClassLoader.withClassLoader` installs), Trino's `GravitinoConnectorPluginManager` (fresh per-plugin `PluginClassLoader`), and `BuiltInJobTemplateEventListener` (a throwaway `URLClassLoader` that's _closed_ right after — caching across it would be actively unsafe). A global cache would bind whichever impl loaded first. > > **The one genuine analog:** `GravitinoCatalogStore` (flink-connector) re-scans the Flink `Factory` SPI on every `storeCatalog`/`getCatalog`, no cache. It's cacheable, but it uses single-arg `ServiceLoader.load(Factory.class)` (thread-context CL, which Flink may swap to a user-code CL), so it'd want a per-classloader cache rather than a plain static map — and the win is smaller than the per-request credential path. Happy to do it as a separate follow-up if you think it's worth it. It seems that the ROI of letting more SPI use cache is not high, so the current state is acceptable to me. We can continue to optimize it if needed in the future. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
