Persistent数据库开发

Persistent数据库不是某个数据库，而是一种性质。一个database 是 persistent的，iff 系统重启以后它原有的数据不会丢失。

之前开发的Berkeley DB经常出现死锁现象，后来web application要部署到云端，需要稳定，我就放弃了数据的persistent, 把所有数据改成了内存内的存储（应用暂时的数据存储量还不大，所以内存存储也是合适的），牺牲一点persistency, 换来系统的stability.

软件在不断发展，用户也越来越多，之前留下的这个technical debt越发严重，数据不persistent会导致用户的confusion, 我举个例子。某个button在每轮regression以后都需要被点击一次，点击后它会变成另外的颜色，如果系统一直运行着，那没有什么问题，在有时我会在下午左右的时间更新一个版本，这时候需要把系统关闭并重启，这之后原有的点过button的数据就丢失了，用户再进入之前的页面以后就会觉得我是不是当时忘记点了，于是就再点了一次，造成了更多人的confusion(是由这个button的action造成的，这里不细说）。

所以以上就是persistent数据库的需求，我作为dev需要解决这个问题。我分析了一下之前死锁的问题是很多线程在共用一个environment（在Berkeley DB JE的时间里database叫做environment），有些想要关掉，有些想要使用，这就产生了race condition. 加锁的难度很大，于是我就把不同范围的数据放到不同的environment里面，Berkeley DB的environment是本地磁盘的一个目录，你可以指定不同的目录去创建不同的environment。我就是这么做的。

其实这是很简单的想法，为什么值得写一下呢？因为这个一个over-generalization的错误。Lambert说过 Don’t generalize. Generalization is generally wrong. 之前的开发把所有数据库都建设在一个environment下面，又开发了database factory, 各个database class 都继承同一个抽象类，搞了多态等一系列复杂的面向对象编程技巧。然而现在发现，这些开发都基于一个现实就是environment不变，现在environment需要变，之前的一切都需要被改变。我并不因为之前的努力白费而懊恼，相反我对自己的代码时刻需要改动感到高兴，因为这些代码是活的，它们在不断改变，有强大的生命力。