Titus Brown wrote:

>-> >I know this isn't the solution you wanted, but it's something you might
>-> >consider:
>-> >
>-> >http://www.danga.com/memcached/
>-> >
>-> >There's a Python API for it, too.
>->
>-> It wasn't quite what I had in mind, but thanks all the same! I was
>-> looking for one of these as well. ;-)
>
>I'm glad I could help ;).
>
>I just wrote a fairly simple example of a memcache sessions
>implementation (modified from my SQL example).  A Darcs repository
>is at
>
>       http://darcs.idyll.org/~t/projects/qx-memcache-example/
>
>and a tarball is at
>
>       http://darcs.idyll.org/~t/projects/qx-memcache-example-dist.tar.gz
>
>It's persistent in the sense that as long as the memcache daemon is
>running, your users/sessions will be persistent across SCGI processes.
>Right now there's no mechanism to save either sessions or users to disk,
>however.  (I wrote it because I was curious about how the memcache API
>worked.)
>
>
You've got me curious, too. ;-) One nagging feeling I had about my
nefarious session-affinity scheme was that if one of the SCGI processes
hanged unexpectedly, I could lose crucial data. In hindsight, I was
optimising prematurely, dazzled by the possibilities of a super-scalable
design (and ignoring the obvious risks). The datasets I'm dealing with
aren't *that* large... if memcached lives up to its performance claims,
it would be more than suitable.

I think memcached and I are about to embark upon a long, fruitful
relationship. Thanks again for the introduction!

-- Graham