On Fri, 8 Apr 2005, Barry Pearce wrote:

> I already have file based sessions that we implemented some time ago. We u
se a number of items:
>
> Firstly I use the time since epoch in hex, then add the 4 numbers of the c
lient IP address and the
> we append a 32bit random number - which then gives you something that looks like t
his:

this is pretty much what the _new_sid() is Session.py does (it also adds
the pid to the mix)

> If you several thousand in the same dir causes problems - then simply use it as a 
dir path.

I think should run some tests to see how much of a big deal this really
is. If you have 10000 active sessions you're bound to have other problems
elsewhere and I doubt that the session lookup is going to be your main
slowdown, so I propose we table this discussion until later.

> 4c34ef90/081/364f1a9c

This won't work with _new_sid() because it uses MD5 so session id's aren't
likely to be alike. But it's a moot point - see above pargraph.

> I use a .lck file - can avoid race conditions, and more importantly
> doesnt rely on o/s capabilities

what's a .lck file? locking by definition *must* be an OS capability or
else it _is_ subject to race conditions.

> (such as lockf - which doesnt work anyway in a multi-threaded
> environment.)

Current locking uses the APR's global locking mechanism which decides
based on OS and the httpd config/compile options what the most efficient
locking mechanism is. There is no reason to reinvent the wheel here - it's
a complex problem that I trust the APR folks are most qualified to solve.

Grisha

[ Post a follow-up to this message ]