beaker之session问题

beaker提供了对session和cache的访问，它是一个独立的库，用在pylons中。uliweb中也使用了它，这是可以找到的功能完整的包。不过最近在uliweb中，shuhanwu反映一个问题：

当使用api访问uliweb时，他使用的是文件方式，因为不带cookie，所以会创建非常多的session文件，占用硬盘空间很大，并且在程序中并没有对session的处理。

于是我开始研究beaker库。这个库说实在的，怎么说呢？有些乱，而且还包含了一些基本用不上的东西，比如：CookieSession。它支持多种后端，比如：文件，dbm，数据库等。它的层次挺多，比如有：SessionProxy，Session，Namespace等。通过SessionProxy来决定是使用Session还是CookieSession，然后每个Session对象对应一个Namespace，每个Namespace对应一种存储方式。Session有基本的load和save方法，在处理时会进行加锁处理。加锁有两层，一层是使用threading.Lock类，一层是使用文件系统，这种方式在windows下无效。在某些后端如Google的支持，就没有文件锁了。所以仔细想一想，beaker的session其实是不支持集群，对windows的支持有限，并且没有使用数据库的加锁机制。

那么问题是怎么产生的呢？原因就是在load时，如果文件还不存在，则beaker会自动创建。而由于客户端不带cookie，所以永远找不到后台保存的session文件，所以会一个请求就创建一个，因此文件会越来越多。现在的session生成，都不带清除的，而是让你写一个脚本去清。

先不管beaker的功能强弱，但是知道了问题却不是太好改。因为有些代码在读和写时是重叠的，比如do_open()，如果读时不存在，不创建文件，但是写也要使用这个函数，则也不会创建，则后面的保存就会失败。如果加以区别的话，其它的manager的类都要修改，动作就太大了。为什么会这样？我想是因为底层的存储与session本身没有有效的隔离，在Session类中会直接操作namespace['session']这样的处理，而不是在从namespace中load出session数据后与namespace分离，这样造成了紧耦合。总之，不是一两句可以说得清。beaker程序也是读了有阵子才是越来越明白，但是改起来还是太麻烦感觉。

想使用其它的session库替换，象werkzeug，功能太弱，比如没有锁机制，好象过期也没见着，目前只有文件支持，没有数据库支持。django目前是支持多种，文件支持也没有使用文件锁，看代码是说通过创建临时文件，然后改名来实现的，不过没有太弄明白。有时间试着把beaker改一下吧，不过难度挺高。