"No, I mean session management. Example of anemia: it offers no way to back sessions by persistent storage."
The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. The support is there to have persistent session objects, you just need to find something that does that (I agree it would be great to have libraries independent of frameworks but built for specific DBs for this) or do it yourself (all that Hunchentoot requires for this to work is to implement two methods).
A lot of the time what you'd really want to do is subclass the session class to make it persistent through an ORM or prevalence, but the problem is that you can't just drop in arbitrary metaclasses into arbitrary subclasses in CLOS.
"Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions?
It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled, reload the code, and then resume processing requests."
You're talking about atomic change management. Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions (for example, people in the middle of a multi-step order confirmation form)? The easiest way to do this is have multiple servers and switch them over one by one. In the more general case you need to think in terms of protocols and protocol versioning (http://carcaddar.blogspot.com/2009/03/p-cos-blew-my-mind.htm...)
Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions
Good point.
The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do.
I notice you used the plural "frameworks" built on top of Hunchentoot. Are there any aside from Weblocks?
The session protocol is a bit awkward in that you need to implement all of it if you want to change only a small part, but it's there to be hooked into, which is what the frameworks built on top of Hunchentoot do. The support is there to have persistent session objects, you just need to find something that does that (I agree it would be great to have libraries independent of frameworks but built for specific DBs for this) or do it yourself (all that Hunchentoot requires for this to work is to implement two methods).
A lot of the time what you'd really want to do is subclass the session class to make it persistent through an ORM or prevalence, but the problem is that you can't just drop in arbitrary metaclasses into arbitrary subclasses in CLOS.
"Really? What about threads that are busy processing requests when you load the new code, which may have different assumptions? It seems like a better approach would be to queue up incoming requests, wait for existing requests to be handled, reload the code, and then resume processing requests."
You're talking about atomic change management. Queueing up requests works on a per-request basis, but what happens when your code changes affect existing sessions (for example, people in the middle of a multi-step order confirmation form)? The easiest way to do this is have multiple servers and switch them over one by one. In the more general case you need to think in terms of protocols and protocol versioning (http://carcaddar.blogspot.com/2009/03/p-cos-blew-my-mind.htm...)