Sticky for shopping carts with disabled cookies

Unanswered Question

How are the rest of you handling sticky (for the purpose of a session id based shopping cart) for your users who have cookies disabled in their browsers?

I know there is the secondary cookie option, but I can't see how it can possibly work when the load balancer is always a step ahead/behind the web server assigning the session id. I can think of a few solutions to make this work, but it all involves some changes on the web application side, which of course, developers are reluctant to consider.

Can any of you tell me how you handle it on your e-commerce sites?



Here's some detail of what happens with cookies disabled:

- User goes to website with cookies disabled

- ACE puts no entry in the sticky database because there's no cookie nor is there a session id in the URL

- ACE sends user to server 1

- Server 1 sees new user, assigns session ID, appends session ID to a query string in all the hyperlinks on the page

- User clicks on a hyperlink with an embedded session ID

- ACE receives request, sees session ID, looks up session ID in the sticky database, no entry, so ACE assigns server to user, next in line is server 2, and puts an entry into the sticky database

- Server 2 sees request and finds session ID. Server 2 has no recollection of session ID since it was created on server 1.

- Server 2 assigns new session ID and appends the session ID to all the hyperlinks on the page

- User clicks hyperlink.

- ACE gets request, sees the session ID and looks it up in the sticky data

- It's a new session ID, so there's no entry.

- ACE assigns a server to the user and puts a new entry in the sticky database.

- And on and on and on...

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
agiaccone Thu, 04/17/2008 - 13:50

Have you considered using the sticky source ip feature ?

If the service intended for internet users, using a right timeout you could easily reach the desired effect i.e. to stick one user on the first server hit, and maintain a good load balancing of sessions (much ips all different).

If the problem are users behind proxies, I think the secondary cookie option is the best.




This Discussion