I agree that serializing everything would be counterproductive (though the impact could be reduced by limiting synchronization to methods with the Map return signature.) I wonder if it would be possible to implement a lightweight scheme using update counts, though.
Otherwise it's probably a bad idea to ever have lifecycle and bind methods that both update service properties. And, unfortunately, that may not be all that obvious because the updates will happen in the expected order most of the time. I'm not sure if modifying service properties is documented somewhere (I couldn't find anything), but if it is this should probably be mentioned there. On Mon, Apr 10, 2017 at 3:28 PM, David Jencks <[email protected]> wrote: > I don’t think this is a bug. To avoid this behavior I think we’d have to > serialize all lifecycle method invocations which I believe to be very > undesirable. > > I could be wrong. > > david jencks > > > On Apr 10, 2017, at 2:39 PM, Brent Daniel <[email protected]> > wrote: > > > > Should there be any guarantees on the ordering of service property > updates > > across methods? > > > > For example, say I have an activate method that simply returns the > current > > service properties and a bind method that adds "active=true" to the > current > > properties and returns the updated properties. Both methods are > > synchronized. > > > > Let's say activate() is invoked first and exits. Before Felix updates the > > service properties, another thread calls the bind method, and Felix > updates > > the service properties to contain "active=true". Then the first thread > > updates the service properties to the set returned from the activate() > > method, thus blowing away the changes from the bind method. > > > > Is this a bug? Or should we not be relying on the property updates from > the > > first method being called taking effect before the second method's > updates? > >
