Request-scoped PolarisMetaStoreManager #2555
Conversation
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
4 times, most recently
from
9738d71 to
c014ca0
Compare
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
8 times, most recently
from
c1b2564 to
4511b5e
Compare
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
3 times, most recently
from
ebc2443 to
e9f1079
Compare
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
from
e9f1079 to
88db62e
Compare
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
from
88db62e to
d1dda2e
Compare
| public PolarisMetaStoreManager createMetaStoreManager( | ||
| RealmContext realmContext, @Nullable RealmConfig realmConfig) { | ||
| if (realmConfig == null) { | ||
| realmConfig = new RealmConfigImpl(configurationStore, realmContext); |
There was a problem hiding this comment.
Do we need the realmConfig parameter at all?
There was a problem hiding this comment.
as we can build it ourselves its not strictly needed no, but many call sites already have it and can pass it in.
i am fine to remove the parameter if we think thats better overall.
| public class InMemoryEntityCache implements EntityCache { | ||
|
|
||
| private final PolarisDiagnostics diagnostics; | ||
| private final PolarisMetaStoreManager polarisMetaStoreManager; |
There was a problem hiding this comment.
I suppose InMemoryEntityCache must use a PolarisMetaStoreManager from the same realm. If PolarisMetaStoreManager is a method parameter it become not so obvious. WDYT about keeping this field?
There was a problem hiding this comment.
afaict we cant keep this field as PolarisMetaStoreManager now represents a (per-request) persistence session where-as InMemoryEntityCache is supposed to be a shared cache within a realm.
the question is with what persistence session do we want to populate the cache?
a shared one or the request-scoped one given by the callers as "use this for loading in case cache entry is missing" ?
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
from
d1dda2e to
37696b7
Compare
|
rebased after trivial a conflict and also to adjust to |
the `PolarisMetaStoreManager` interface methods all take a `PolarisCallContext` parameter because they need access to `PolarisCallContext.getMetaStore` aka the persistence session. also occasionally the `RealmContext` and `RealmConfig` is needed. this means `PolarisMetaStoreManager` is only usable within a request-scope. `MetaStoreManagerFactory.getOrCreateMetaStoreManager` impls suggests that there needs to be one shared `PolarisMetaStoreManager` instance per realm. however if we look at the `PolarisMetaStoreManager` impls (`AtomicOperationMetaStoreManager` and `TransactionalMetaStoreManagerImpl`) we can see that they dont have any state themselves, the fields only reference application-scoped collaborators. those 2 observations combined mean that in order to reduce the dependency on `PolarisCallContext` the `PolarisMetaStoreManager` has to become request-scoped. note that if custom implementations would need any state sharing for a realm, they are still free to do so in their custom `MetaStoreManagerFactory` implementations, as they can initialize the request-scoped `PolarisMetaStoreManager` with whatever data they need. when `PolarisMetaStoreManager` is request-scoped the `getOrCreateSession` method also becomes a private implementation detail of the `MetaStoreManagerFactory`. the `EntityCache` / `InMemoryEntityCache` however can no longer operate on a single `PolarisMetaStoreManager` and the one from the request needs to be passed as a parameter in all the methods now.
XN137
force-pushed
the
request-scoped-PolarisMetaStoreManager
branch
from
37696b7 to
5007ca1
Compare
2 participants
see ML discussion:
https://lists.apache.org/thread/ot19px6t0w808pp994rrc8kk7186dfxm
the
PolarisMetaStoreManagerinterface methods all take aPolarisCallContextparameterbecause they need access to
PolarisCallContext.getMetaStoreaka the persistence session.also occasionally the
RealmContextandRealmConfigis needed.this means
PolarisMetaStoreManageris only usable within a request-scope.MetaStoreManagerFactory.getOrCreateMetaStoreManagerimpls suggests that there needs tobe one shared
PolarisMetaStoreManagerinstance per realm.however if we look at the
PolarisMetaStoreManagerimpls (AtomicOperationMetaStoreManagerand
TransactionalMetaStoreManagerImpl) we can see that they dont have any state themselves, the fields only reference application-scoped instances.Those 2 observations combined mean that we can make the
PolarisMetaStoreManagerrequest-scoped and then thePolarisCallContextparameter can be removed from all the methods without losing any functionality/flexibility.note that if custom implementations would need any state sharing for a realm, they are still free to do so in their custom
MetaStoreManagerFactoryimplementations, as they caninitialize the custom request-scoped
PolarisMetaStoreManagerinstance with whatever (shared) data they need.when
PolarisMetaStoreManageris request-scoped thegetOrCreateSessionmethod also becomes a private implementation detail of theMetaStoreManagerFactory.