Update a Resource and Recover Applications

Classify the complete effective edit before activation. The following table distinguishes configuration replacement from terminal invalidation.

Event	Effect	Required Action
Rejected proposal, prepared rollback, unchanged activation	Active generation preserved	Correct or discard the proposal
Valid compatible property-only update preserving name/provider/type/JNDI/default selection	Provider replacement behind stable handles	Reacquire former-generation capabilities
Accepted selection-affecting or provider-incompatible update	Dependent deployment terminally invalidated	Restore configuration and fully redeploy
Removal, untargeting, or unavailability that invalidates a deployment	Existing deployment cannot resume by ordinary stop/start	Restore availability and fully redeploy
Changed application binding/global identity	New deployment generation required	Fully redeploy with intended descriptors

Compatible property updates can change an endpoint, database name, or protected credential. They do not migrate data, validate schema compatibility, or guarantee endpoint availability.

Previously admitted operations drain before the old runtime closes. Former-generation retained capabilities are rejected. Failure to construct the new provider does not restore the old generation. An otherwise valid stable handle can retry creation.

After terminal invalidation, retargeting, ordinary stop/start, an administration-mode transition, or a later compatible update does not restore the deployment. For an EAR, recover the complete affected application rather than assuming a module-only refresh is sufficient.