On Feb 14, 2014, at 2:31 AM, peter p2.edoc@gmail.com wrote:
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.
Turns out to be very easy. HT sessions can be accessed and set via the generic function ht:session-db, which returns an alist. The alist keys are fixnums and the values are opaque HT::SESSION objects. To make a persistent session all you have to do is serialize and restore this alist. All of the slots of an HT::SESSION are atoms, except for HT::SESSION-DATA, which is an alist, but it contains only values that you put there. So serializing an HT::SESSION is not hard.
The challenging part for me turned out to be restoring Hunchentoot’s internal session state on restart, because HT assumes that there is an active request whenever a session is created:
? (make-instance 'ht::session)
Error: Unbound variable: *REQUEST*
So you have to restore sessions using ALLOCATE-INSTANCE instead of MAKE-INSTANCE. Other than that it is completely straightforward. (I ended up writing a little general-purpose object serializer using the MOP.)
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.
Not sure I understand this. HT natively provides unique (per server) session id’s. If you want to make session id’s unique across multiple servers that is a different problem than making sessions persistent. But HT already has a hook for that: the generic function NEXT-SESSION-ID. Is there a reason that doesn’t work for you?
rg