LEARN. PRACTICE. GROW.State travels with the release
A WebSphere release involves more than the EAR. Configuration, data, session classes, and dependencies can coexist in different versions during the window. An application that starts is not necessarily ready to read state produced by the next version. In the workshop, the old reader requires account and amount; the new writer keeps account, uses units, and removes amount. The old contract is no longer satisfied. This is a synthetic compatibility example, not executed Java serialization. Before the window, identify readers, writers, shared state, and permitted transitions. Connect those elements to recovery planning so rollback has a functional meaning.
New and existing sessions
A new-login test covers session creation. It does not automatically cover a user who saved a draft before their member left service. For that situation, create identifiable state, confirm its value, perform the authorized transition, and check the content afterward. Affinity and persistence serve different purposes; the former does not establish that the draft exists on another member. The persistence strategy needs assessment with actual application classes and versions. Include member transitions in both directions when they can occur during recovery. Criteria should cover data and user experience as well as process availability and cookie issuance.
Capacity while a member is out
Relevant capacity during an update is the capacity of members that remain available. In the lesson model, three equivalent members each support 60 requests/s and receive 150 requests/s. Removing one leaves 120 requests/s, a shortfall of 30. This calculation is not a benchmark and assumes ideal distribution; affinity, request sizes, and shared dependencies may make the real result worse. Use representative measurements to decide admissible load, timing, and headroom. If demand cannot be reduced with authorization and remaining capacity is insufficient, change the plan before removing the member. A cluster is a topology, not an automatic continuity guarantee.
Observe the candidate without hiding it in totals
The lab calculates rates for 20 errors in 10000 control requests and 12 in 200 candidate requests. These are 0.2% and 6%, while the aggregate is roughly 0.314%. Larger control volume hides part of the candidate signal. The thirtyfold rate ratio is an observation, not statistical or causal proof. Compare paths, state, and group composition. If the candidate receives only anonymous reads, you are not testing a change to authenticated sessions. If it receives only old state, record that difference. Keep the issue visible and limit exposure while reproducing the affected transition against criteria defined before expansion.
Recovery with uncertain outcomes
A response lost during the window does not prove that the backend operation failed. In a fictional subscription request, the client times out after sending the POST and business confirmation remains unknown. Identify the business reference, reconcile the result, and apply the idempotency policy before retrying. Plugin retry behavior depends on configuration and conditions; it does not guarantee a single business effect. Recovery must also consider state written by the new version. If the old reader cannot handle it, choosing the old EAR is insufficient. Compare rehearsed recovery and any forward fix with owners, available time, and preservation of valid work.
Expansion decision and operational record
Prepare a guide with the tested application and configuration combination, affected members, request profiles, error limits, minimum capacity, and decision deadline. If v8 with c5 was rehearsed and the window proposes c6, assess the difference before reusing acceptance. During the operation, a schedule does not require expanding a stage with unexplained errors. Hold, communicate impact, and apply agreed recovery criteria. At completion, hand RUN teams results by path, limitations, references for reconciled operations, and owners for outstanding work. Local exercises help prepare this decision; they do not replace an authorized trial or human middleware review.
# SYNTHETIC RELEASE EXERCISES; no WebSphere deployment
control_error_rate = 20 / 10000 # 0.2%
candidate_error_rate = 12 / 200 # 6%
remaining_capacity = 2 * 60 # 120 requests/s
demand = 150 # shortfall: 30 requests/s
# Old reader requires amount; new state contains units instead.
# Reconcile business-71 before deciding whether replay is safe.A global rate of 0.314% hides 6% in the candidate. The team holds expansion and compares equivalent sessions before concluding the cause.
Common pitfalls
Testing only new logins; ignoring capacity with one member out; accepting global averages; confusing restart with data recovery; retrying POST without reconciliation.
Related topics: Deployment and routing · JDBC and transactions · Maintenance and recovery
Expand when evidence covers the change and existing state. Useful recovery preserves valid work and confirms the functional path.
Reference: Canarying Releases · BigSavant WebSphere traditional ND 9.0.5; maintenance baseline 9.0.5.29 (2026-09-08); documentation reviewed 2026-09-30