Hi David, Am 23.02.2013 um 23:42 schrieb David Jencks: > There's a race condition in DS between registering a new component holder for > existing configuration and processing configuration events. Before > FELIX-3912 it was possible to completely miss a configuration for a new > component holder if the configuration arrived between the query for existing > configurations and the registration of the holder for configuration updates. > I switched the order, and now there's a chance a configuration update will be > applied twice. (even after my second commit on this) > > Is this a problem?
I think not. It is probably better to have a chance of double configuration than to have a risk of missing configuration. The latest Config Admin spec introduces a revision counter to the Configuration object. DS could check that -- but this would require the latest Config Admin spec. Not sure, whether this would be worth it. > > I think a solution would be to register a ManagedService or > ManagedServiceFactory for each component holder, since then the initial > configuration and all updates would occur on the same thread. This seems > like a lot of services…. Yes, and it does not help. (a) MS and MSF are also called asynchronously and (b) to support both factory and singleton configurations (whatever is present) both MS and MSF would be required. Even more services. > > I haven't thought much but I think to distinguish between MS and MSF we need > to query the initial set and look for events to determine whether there's a > factoryPID or just PID and use that to decide. If there is no initial configuration you don't have anything to decide on ... > > Thoughts? Any other ideas? I think it suffices it to register before checking and risk "double" configuration in edge cases. Regards Felix > > many thanks > david jencks > -- Felix Meschberger | Principal Scientist | Adobe
