Hi Chetan I agree that we should not rely on the service.ranking for this. A type property makes sense IMO.
On the other hand, do we really need to expose both NodeStores in the service registry? The secondary (cache) NodeStore could also be treated as an implementation detail of the DocumentNodeStore and switched on/off via configuration. Of course the devil is in the detail then - how to configure different BlobStores, cache sizes etc of the secondary NodeStore? Not exposing the secondary NodeStore in the service registry would be backwards compatible. Introducing the "type" property potentially breaks existing consumers, i.e. is not backwards compatible. Regards Julian On Tue, Jun 21, 2016 at 9:03 AM, Chetan Mehrotra <[email protected]> wrote: > Hi Team, > > As part of OAK-4180 feature around using another NodeStore as a local > cache for a remote Document store I would need to register another > NodeStore instance (for now a SegmentNodeStore - OAK-4490) with the > OSGi service registry. > > This instance would then be used by SecondaryStoreCacheService to save > NodeState under certain paths locally and use it later for reads. > > With this change we would have a situation where there would be > multiple NodeStore instance in same service registry. This can confuse > some component which have a dependency on NodeStore as a reference and > we need to ensure they bind to correct NodeStore instance. > > Proposal A - Use a 'type' service property to distinguish > ========================================== > > Register the NodeStore with a 'type' property. For now the value can > be 'primary' or 'secondary'. When any component registers the > NodeStore it also provides the type property. > > On user side the reference needs to provide which type of NodeStore it > needs to bound > > This would ensure that user of NodeStore get bound to correct type. > > if we use service.ranking then it can cause a race condition where the > secondary instance may get bound untill primary comes up > > Looking for feedback on what approach to take > > Chetan Mehrotra
