PeopleSoft PIA Session Timeout & Load Balancer Sticky Cookie Tuning

Overview

PeopleSoft PIA is a stateful, multi-tier web application. A user’s session lives in the WebLogic HTTP session of a single PIA web server (web profile state, component buffer references, and authentication tokens). When an enterprise load balancer distributes requests across multiple PIA nodes without session persistence — or when any tier’s idle timeout fires before the application’s own timeout — users experience:

• Sudden redirects to the signon page mid-transaction
• “You have been signed out due to inactivity” messages despite active work
• Lost page-level data when saving
• Intermittent PS_TOKEN validation failures on specific nodes

The timeout hierarchy must be strictly ordered, from shortest to longest:

LB idle timeout  <  WebLogic session-timeout  <  PeopleSoft web profile timeout

Diagnostic Checklist

Run the following on the PIA web tier and load balancer to establish the current timeout and persistence posture.

1. Extract the effective WebLogic session timeout (web.xml):

cd $PS_HOME/webserv/peoplesoft/applications/peoplesoft/PORTAL.war/WEB-INF
grep -A3 "session-timeout" web.xml

2. Check the PeopleSoft web profile timeout settings (via SQL):

SELECT OPRID, WEBPROFILE, TIMEOUT_SVC, ENABLE_TIMEOUT
  FROM PSWEBPROFSEC
 WHERE WEBPROFILE = 'PROD';

Also inspect PSWEBPROFNODATA, PSWEBPROFSEC timeout values — the web profile “Timeout Interval” and “Timeout Prompt Interval” define the PIA-level inactivity window.

3. Verify sticky cookie presence in a captured response:

curl -skI https://psprod.example.com/psp/ps/ | grep -i "set-cookie"
# Expect: BIGipServer<pool>=<encoded-ip>.<port>.0000  (F5 cookie insert)
#     or: JSESSIONID=...; Path=/psp/ps (native affinity)

4. Confirm WebLogic session replication / persistence (if not using LB stickiness):

grep -r "persistent-store-type" $PS_HOME/webserv/peoplesoft/config/config.xml
grep -r "session-descriptor" $PS_HOME/webserv/peoplesoft/

5. Check LB idle timeout vs. longest transaction (F5):

tmsh list ltm virtual-session-server ps_pia_pool persist
tmsh list ltm pool ps_pia_pool | grep -i "timeout"

6. Review PIA access logs for session churn patterns:

grep -c "signon.html" $PS_HOME/webserv/peoplesoft/logs/access.log
awk '{print $1}' $PS_HOME/webserv/peoplesoft/logs/access.log | sort | uniq -c | sort -rn | head

A high ratio of signon page hits from the same client IP within short intervals indicates repeated forced re-authentication — the classic stickiness failure signature.

Step-by-Step Resolution Runbook

Step 0 — Safety Checks

• Confirm a valid backup of $PS_HOME/webserv/peoplesoft/config/config.xml and all web.xml files before modification.
• Verify change window and that both PIA nodes are in the LB pool; document current pool member states (tmsh show ltm pool ps_pia_pool).
• Confirm no active batch/integration jobs (Integration Broker, Process Scheduler UI sessions) rely on the PIA nodes being modified.
• Snapshot the F5/NGINX configuration (tmsh save sys config or nginx -T > /backup/nginx.conf.bak).

Step 1 — Establish the Timeout Hierarchy

Set values so the LB never fires first. Recommended baseline for a 30-minute PeopleSoft web profile timeout:

Tier	Parameter	Value
Load Balancer (F5 TCP profile)	Idle Timeout	3600 sec (60 min)
WebLogic web.xml	session-timeout	60 (minutes)
PeopleSoft Web Profile	Timeout Interval	30 min
Web Profile	Timeout Prompt Interval	5 min

Edit web.xml:

<session-config>
  <session-timeout>60</session-timeout>
</session-config>

Restart the PIA web server domain afterward:

$PS_HOME/webserv/peoplesoft/bin/stopPIA.sh
$PS_HOME/webserv/peoplesoft/bin/startPIA.sh

Step 2 — Configure Load Balancer Sticky Persistence (F5)

Use cookie insert persistence so the LB manages affinity without relying on WebLogic session cookies:

tmsh create ltm persistence cookie ps_cookie_insert \
  method insert cookie-name PSPIASTICK expiration 3600

tmsh modify ltm virtual-server ps_pia_vip \
  persist replace-all-with { ps_cookie_insert }

Key tuning points:

• Set cookie expiration greater than the WebLogic session timeout (e.g., 3600 sec for a 60-min session) so the sticky entry never expires before the session.
• Use cookie-name distinct from JSESSIONID to avoid conflicts.
• For HTTPS VIPs, ensure the cookie is not marked secure incorrectly if HTTP health checks are in play.

For NGINX tiers, open-source NGINX supports ip_hash or consistent hashing on the JSESSIONID cookie, while commercial NGINX Plus provides native sticky cookie insertion:

# Option A: Open-Source NGINX (Consistent Hashing on JSESSIONID)
upstream ps_pia {
    hash $cookie_jsessionid consistent;
    server pia01.example.com:8000;
    server pia02.example.com:8000;
}

# Option B: NGINX Plus (Commercial Native Cookie Insertion)
# upstream ps_pia {
#     sticky cookie PSPIASTICK expires=1h domain=.example.com path=/;
#     server pia01.example.com:8000;
#     server pia02.example.com:8000;
# }

Step 3 — Validate Session Affinity

Confirm consecutive requests land on the same node:

for i in 1 2 3 4 5; do
  curl -sk -c /tmp/ps.jar -b /tmp/ps.jar \
    https://psprod.example.com/psp/ps/?cmd=login -o /dev/null -w "%{http_code}\n"
done
grep -i "BIGipServer\|PSPIASTICK" /tmp/ps.jar

On the F5, verify persistence records:

tmsh show sys connection | grep -A2 "ps_pia_vip"

Step 4 — Tune WebLogic Session Management (Optional HA Path)

If you prefer session replication over stickiness (active-active), enable in-memory replication in config.xml per PIA server and ensure the deployment is clustered. Note: PeopleSoft does not fully support session replication for all component contexts; sticky persistence is the vendor-recommended pattern. Only pursue replication after validating with Oracle/PeopleSoft support guidance.

Step 5 — Align PeopleSoft Web Profile

Navigate in PIA: PeopleTools → Web Profile → Web Profile Configuration → Look and Feel → Timeout. Set:

• Timeout Interval: 30 (minutes)
• Timeout Prompt Interval: 5 (minutes)

Ensure ENABLE_TIMEOUT is consistent across all web profiles in use, and that the PT_TIMEOUT refresh mechanism is not blocked by a proxy caching signon.html.

Step 6 — Post-Change Verification

• Run a full transaction (e.g., open a component, idle 25 minutes, save) — session must survive.
• Kill one PIA node and confirm the LB drains gracefully; users on the failed node will lose sessions (expected with stickiness) — document this in the DR runbook.
• Monitor access.log signon ratios for 24 hours to confirm churn reduction.

📚 Official Documentation & Technical References

• Oracle PeopleBooks: System and Server Administration — Web Profile Configuration (PeopleTools 8.59/8.60)
• Oracle WebLogic Server Documentation: Configuring HTTP Session Management in WebLogic Server
• F5 BIG-IP LTM Documentation: Overview of BIG-IP Cookie Persistence Methods
• Nginx HTTP Upstream Module: Module ngx_http_upstream_module Load Balancing & Hashing

---

Session churn and timeout misalignment degrade user productivity and inflate helpdesk volume. DBPros.Net architects specialize in PeopleSoft PIA, WebLogic, and enterprise load balancer tuning. Contact Us for a PIA session architecture assessment or Explore Our Services for managed PeopleSoft infrastructure support.