I am still wondering what is the best way to deploy updated 
bundles/configurations with the help of the JCR Installer and FileVault 
packages while preventing to much restart of services on the OSGi level.

The problem is that for an update there is the slight chance, that the deletion 
of the old bundle/config and the addition of the new bundle/config is not 
processed in the same cycle of the OSGi installer. In case this happens, then a 
lot more starting/stopping of services/bundles happens as instead of the 
upgrade an individual delete followed by an individual addition is detected.

What is the recommended way of minimizing that risk in my package?

The following options come to my mind:
1. Do not delete the old artifact (only possible for bundles, as the node name 
includes the version number by default). To achieve that the filter roots only 
point to the simple file aggregates covering the current bundle only (and not 
touching the old one)
2. Make sure that you have dedicated root entries for the the bundles/configs 
only (e.g. "/apps/myapp/install"). I am not sure though if this actually makes 
a difference in terms of how much this minimizes the timespan of old artifacts 
being deleted and new artifacts being added. In most of the cases the deletion 
as well as the addition should anyhow be done in the same JCR session (as an 
autocommit only happens every 1024 nodes).

Are there any other choices?
What is the recommended way here?

Thanks for your input,
Konrad

Reply via email to