Attribute Persistence

[dimitris]

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.

[dimitris]

I'm not sure how this fits in with what we have now.

If you turn the mbean in question to xmbean, using the AttributePersistenceService as backend, then you can explicitly ask for the removal of it's saved attributes.

Would that be equivalent to what you want to achieve?

[sebersole]

Well the main limitation with that is that it forces everything to be an xmbean deployment, correct?

To me it seems much more generally applicable than that and achievable for non-xmbean deployments as well.

But I'm not an expert here by any stretch ;)

[dimitris]

Yes but how you'll manage to persist attribute changes through the console or some other external means? Or you mean you only want to persist changes through the "admin" console?

[sebersole]

Well that is one way to do it. In fact, initially the scope of our discussion was limited to the admin console and how we might achieve configuration persistence there. But thats when Ivelin brought up that this was being discussed in terms of the app server as a whole. And really, I think whatever we do here needs to be done in terms of the app server as a whole; it does not make much sense to have some changes from certain sources be persistent while others are not.

If xmbeans are the correct way to achieve this, then ok thats what I'll use. But I don't think that will get me the timestamping thing I was talking about (there is still only a single notion of the xmbean descriptor).

More what I was thinking was something that ties into the ServiceConfigurator/ServiceCreator processing of building and configuring an mbean.

Initially what we talked about was perhaps deploying the stuff to be managed as xmbeans and using a variation of the AttributePersistenceService which kept the additional information needed to perform the timestamping functionality. But I am not familiar enough with the AttributePersistenceService to know whether that is achievable using this approach.