We seem to be thinking along similar lines…. earlier today I wrote this but got
distracted before sending:
At the moment I don’t see how returning the new service properties from
bimd/updated/unbind methods can be thread safe. I think the
activate/modify/deactivate methods are ok.
I wonder if using the ExtComponentContext to modify the properties and
synchronizing access would lead to deadlocks. Better than this would be a
compare-and-set method of some sort on ExtComponentContext, perhaps based on a
change count
int cc;
Dictionary<String, Object> newProps;
do {
cc = etc.getChangeCount();
newProps = new Hashtable<>(ecc.getProperties());
//update properties
} while (!ecc.compareAndSet(cc, newProps)}
david jencks
> On Apr 11, 2017, at 10:25 AM, Brent Daniel <[email protected]> wrote:
>
> 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?
>>
>>
