Web Sessions on CCv2: Sticky Routing, Cart Binding, Cookies, and the Headless Shift

Sessions are where a lot of commerce weirdness lives: the cart that vanishes, the user logged out mid-checkout, the load that piles onto one node, the monitoring script that inflates the session count. SAP Commerce carries two notions of session at once, routes them stickily across the cluster, and binds the cart to them, and CCv2's managed infrastructure plus the headless shift both change how you reason about all of it. This guide covers the session model, the routing and binding mechanics, the cookie and timeout decisions that are equal parts security and UX, and the move to token-based state that decoupled storefronts bring. It connects to the clustering guide (the aspects sessions route across), the 2FA/session guide (the security posture), and the OIDC guide (the token model).

Two Sessions: HTTP and Jalo#

SAP Commerce runs two session concepts in parallel, and confusing them causes real debugging pain:

• The HTTP session: the servlet container's session, holding web-tier state (the session cookie the browser carries).
• The Jalo/platform session: the platform's own session, holding the user context, active catalog versions, language, and the security context that drives visibility (restrictions, the FlexibleSearch guide).

In normal operation their counts track closely per web application, and a persistent divergence is a diagnostic signal. The classic cause, worth knowing because it recurs: monitoring scripts that hit a URL without being cookie-aware create a new HTTP session per probe, inflating the HTTP count far above the Jalo count. The fix (from the on-premise guide, and it applies conceptually on CCv2) is a health-check endpoint that does not create a session, or a cookie-aware monitor. When session counts look wrong, check what is hitting the nodes before you suspect a leak.

Sticky Routing Across Aspects#

Sessions are sticky: a customer's requests route to the same node so their session state is there. On CCv2 the platform manages this across the accstorefront and api aspects (the clustering guide), but the consequences are yours to design for:

• State lives on one node. Sticky routing means a customer's session is on their node, and if that node recycles (normal cloud weather), the session is gone unless it was externalized. Design flows to tolerate session loss gracefully (re-authenticate, restore cart from persistence) rather than assuming a session survives forever.
• Do not hoard state in the session. Large session objects multiply memory per node and worsen the cost of losing a node. Keep the session lean; persist what must survive (the cart, below) to the model, not just the session.
• Sticky plus uneven hashing can skew load (the on-premise guide's web-server-ordering trap has a CCv2 analog): watch node load distribution, because a stickiness misconfiguration shows up as one hot node, not as an error.

Cart Binding and the Merge Problem#

The cart is bound to the session, and this binding is the source of the most common session-related bug class:

• Anonymous carts attach to the anonymous session. A guest browsing builds a cart tied to their session.
• On login, the anonymous cart must merge into the authenticated user's context. This merge is not automatic-and-obvious; it is a designed behavior with real edge cases: the user had items as a guest and also has a saved cart from a previous logged-in visit, and the merge policy (combine, prefer one, prompt) must be decided. The OIDC and SSO guides flag this as a first-class flow, and it is: login-with-a-full-cart is a test case, not an afterthought.
• Session fixation on login: rotate the session identifier at login and at privilege change (the 2FA/session guide), and make sure the cart-merge flow does not reintroduce a fixation hole, because cart binding is exactly where session-identity bugs hide.
• Cart persistence beyond the session: a cart that exists only in the session dies with the node; carts that matter (saved carts, B2B carts) persist to the model so they survive session loss and are accessible across the customer's devices (the omnichannel guide's cross-channel cart).

Cookies: Security and Behavior#

Session cookies are a security surface and a behavior control:

• Secure always (HTTPS-only, and CCv2 is HTTPS), HttpOnly on the session cookie so scripts cannot read it (XSS mitigation), and SameSite chosen deliberately (Lax as the sane default; None only with a reason, and then necessarily Secure). The security hardening guide treats these as baseline.
• Scope to the narrowest domain that works, so a cookie is not sent where it is not needed (the web architecture guide's endpoint/domain model).
• Verify in the browser, not just the config, because a framework default or a proxy can quietly override what you set, and cookie flags are exactly the kind of thing that looks right in code and wrong on the wire.

Timeouts: A Business Decision#

Session timeout is often left at a framework default, but it is a business decision balancing security and UX:

• Too short and customers get logged out mid-shop or mid-checkout, abandoning carts and generating support contacts.
• Too long and a session left open on a shared or public device is a security exposure (the account-takeover surface the 2FA guide addresses).
• Different contexts warrant different timeouts: a browsing session can be generous; an authenticated, checkout-capable, or B2B-admin session should be tighter, with step-up re-authentication for sensitive actions (the 2FA/session guide) rather than one blunt timeout for everything.

Set the timeout from risk and the shopping-session length your business actually sees, not from the default, and document the choice as an NFR (the NFR catalog guide).

The Headless Shift: State Moves to Tokens#

The decoupled storefront changes the session story fundamentally (the headless and OIDC guides). A composable storefront does not lean on a server-side HTTP session for user state; it holds OAuth tokens and calls OCC statelessly:

• User identity is a token, not a session cookie. Access and refresh tokens (the OIDC guide) carry the authenticated identity; the "session" becomes the refresh-token lifetime, which is your session policy in a token world.
• Cart binding shifts to the OCC cart: the cart is an OCC resource associated with the user (or an anonymous cart identifier), read and written through the API, persisted server-side, and the merge-on-login flow happens through the OCC endpoints rather than through servlet-session mechanics. The problem (merge an anonymous cart on login) is identical; the mechanism is API calls, not session attributes.
• Statelessness is the goal: the OCC tier scales better when it is not hoarding per-user server state, which is why the headless architecture pushes state to the token (client-held) and the persisted cart (server-stored) rather than the session (node-stuck). This is the clustering guide's design-for-horizontal instinct applied to session state.

Most estates run both models during the accelerator-to-composable transition (the storefront strategy guide), so understanding session state in both the servlet-session world and the token world is not optional for a while yet.

Checklist#

• HTTP-versus-Jalo session distinction understood; monitoring that does not inflate HTTP session counts
• Sessions kept lean; state that must survive persisted to the model, not hoarded in the session
• Node-loss tolerated gracefully; load distribution watched for stickiness skew
• Cart binding and merge-on-login designed and tested as a first-class flow, including full-cart login
• Session identifier rotated at login and privilege change; cart merge not reintroducing fixation
• Carts that matter persisted beyond the session for node-loss and cross-device survival
• Cookies Secure/HttpOnly/SameSite, narrowly scoped, verified on the wire
• Session timeout set from risk and real shopping-session length, per context, documented as an NFR
• Headless estates: identity in tokens, cart in OCC, merge through the API, statelessness as the goal

Sessions are invisible when they work and infuriating when they do not, and the failures (vanished carts, mid-checkout logouts, one hot node) all trace back to a handful of decisions about state placement, binding, cookies, and timeouts. Keep sessions lean, persist the cart, secure the cookies, set the timeout deliberately, and treat the login-cart-merge as the real flow it is, and sessions stop being the source of the storefront's strangest bugs.