I find that I have the same requirement and would like not to re-invent wheels so would much appreciate hearing any insights you gained rg.
For local hosting, I used a persistent global session-ID counter as a patch (ensuring session-IDs can't overlap, but that's not acceptable for cloud hosting. All I need really is persistence of the client's cookie validity, as all state data I keep outside HT.
So now I was thinking to modify start-session to be a fork for the make new session case. If the incoming request has no cookie, assume a fresh start so continue as of original start-session, otherwise take this as being an old session, now not found in the session DB. Hence make a replace session.
The session-ID seems irrelevant if I can search of sessions using the session string only. Hence make get-stored-session use string= on the cookie-string.
Ignoring overlapping session-IDs (they begin from 1 each HT boot), I'd need to eliminate reference to session-ID externally and embedded into the cookie string.
But now I get into session-verify etc and expect to run into awkwardnesses. I don't fully understand the use of session-ID, why doesn't HT just use the vanilla cookie-string (without session-ID prefix) ... (despite it obviously being there for some purpose beyond optimized session-DB search). I can't yet get my head around how we can have multiple concurrent sessions to the same client, if that is the original intent. If not then why use the session-id, and why both externally as session-DB index, and internally in the cookie-string as in stringify-session.
peter
At 6:59 PM -0800 14/1/17, Ron Garret wrote:
I need to be able to save and restore HT sessions so that they will survive a server restart. Before I dive into this I thought I would ask if anyone has done this already so I don't reinvent the wheel.
Thanks, rg