I'm copying here an email from Steve:
"Steve Ebersole" wrote:
Let's use a HAR deployment as the example because it represents the simple case of a single mbean component. 2 specific scenarios need to be consider:
1) From one of the consoles, the user changes the attribute values. The server is then restarted. The changes made via the console need to be in effect when the server comes back up.
2) From one of the consoles, the user changes the attribute values. The deployment is then redeployed. The changes made via the console need to be replaced with these new values. So this is where the timestamping comes into play; it is essentially allowing version checks so that we know from which configuration store to read.
When attribute values are changed, these changes are written to the "secondary store". Should not matter where the changes come from...
When a deployment is deployed, MainDeployer and its delegates construct and configure the mbean(s). Additionally, we would need to write the attribute values off somewhere keyed by the deployment url along with the timestamp associated with the deployment url file; this information gets written to the "secondary store".
Now the "trick" comes into play when deploying deployments. Here we need to check the "secondary store" for the entry related to this deployment (if one). If the timestamp indicated on the entry and the timestamp of the deployment url are the same, then the deployment has not physically changed since we last read it into the "secondary store"; thus we should perform the configuration from the "secondary store" representation. However, if the timestamps do not match then the deployment has physically changed; thus we should discard the "secondary store" entry and read from in the deployment descriptor.
Say 'my-hibernate.har' is deployed (with file timestamp x). At that time, the mbean is pointing to "java:/DefaultDS as the datasource. Later, the admin changes the datasource attribute via one of the consoles to be "java:/CustomDS".
Now in the two scenarios mentioned above:
1) The server gets restarted. When we get to 'my-hibernate.har', we notice that it does have a "secondary store" entry. Further, we notice that the timestamp of the entry and the deployment url are the same. So here, we read the configuration from the "secondary store".
2) 'my-hibernate.har' gets redeployed. Supposedly its file timestamp should now be y. x != y, so here we discard the data in the "secondary store" and read from the deployment descriptor.
Another thing we might want to consider that would probably be a nice feature at some point is the ability for administrators to "lock" attribute values. Meaning once the value of a particular attribute is set by the administrator, redeployment does not affect the value of *that* attribute.