INODB consistent read view 的实现
2009-8-11 16:52:56 阅读62 评论0 112009/08 Aug11
INNODB 是一个多版本的数据库引擎，每一条记录在数据库里面可能同时存在多个版本，事务 ID 为版本号。
事务开始时，会首先设置自己可以 view 的事务 ID 的 LIST，涉及源代码如下:
/* No active transaction should be visible, except cr_trx */
while (trx) {
if (ut_dulint_cmp(trx->id, cr_trx_id) != 0
&& (trx->conc_state == TRX_ACTIVE
|| trx->conc_state == TRX_PREPARED)) {
read_view_set_nth_trx_id(view, n, trx->id);
n++;
/* NOTE that a transaction whose trx number is <
trx_sys->max_trx_id can still be active, if it is
in the middle of its commit! Note that when a
transaction starts, we initialize trx->no to
ut_dulint_max. */
if (ut_dulint_cmp(view->low_limit_no, trx->no) > 0) {
view->low_limit_no = trx->no;
}
}
trx = UT_LIST_GET_NEXT(trx_list, trx);
}
view->n_trx_ids = n;
if (n > 0) {
/* The last active transaction has the smallest id: */
view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);
} else {
view->up_limit_id = view->low_limit_id;
}
读取记录时，INNODB 会根据当前事务的ID 来决定取那个版本的数据。
PS 比较简单，之前不了解，把它看得过于神秘了。
事务开始时，会首先设置自己可以 view 的事务 ID 的 LIST，涉及源代码如下:
/* No active transaction should be visible, except cr_trx */
while (trx) {
if (ut_dulint_cmp(trx->id, cr_trx_id) != 0
&& (trx->conc_state == TRX_ACTIVE
|| trx->conc_state == TRX_PREPARED)) {
read_view_set_nth_trx_id(view, n, trx->id);
n++;
/* NOTE that a transaction whose trx number is <
trx_sys->max_trx_id can still be active, if it is
in the middle of its commit! Note that when a
transaction starts, we initialize trx->no to
ut_dulint_max. */
if (ut_dulint_cmp(view->low_limit_no, trx->no) > 0) {
view->low_limit_no = trx->no;
}
}
trx = UT_LIST_GET_NEXT(trx_list, trx);
}
view->n_trx_ids = n;
if (n > 0) {
/* The last active transaction has the smallest id: */
view->up_limit_id = read_view_get_nth_trx_id(view, n - 1);
} else {
view->up_limit_id = view->low_limit_id;
}
读取记录时，INNODB 会根据当前事务的ID 来决定取那个版本的数据。
PS 比较简单，之前不了解，把它看得过于神秘了。
寻找更好的模板系统记
2007-9-11 12:47:35 阅读612 评论6 112007/09 Sept11
无可否认，我已经成了 Google 最忠实的 fans; Google 这次又帮我找到我想要的东西，我又一次对 Google 崇拜的五体投地。
我一直在搜寻一种模板系统，它的速度要快，功能要强，用起来要比较简单。
一开始，我找到了 django 模板系统。和同类模板系统相比，它的速度是最快的，当然比用 C 写的模板系统稍慢一点，但已经非常不错；功能当然非常强，你甚至可以自己定义语法；用起来确实也非常简单。
但我也有追求效率的毛病，如果存在和 Django 模板系统类似，但比 Django 模板效率更高的模板系统，我会马上移情别恋。
这时，我发现了 Jinja 模板系统，它拥有 Django 模板系统的语法，并且具有更高的执行效率。原因很简单，它将模板代码转换成了可执行的 python 代码，并且有相应的 Cache 策略，速度自然要快很多。
Jinja 系统已经非常不错，但可惜的是，我又发现了 Mako 模板系统，它直接用 Python 代码来书写模板里面的逻辑，和前两种模板系统的哲学(Philosophy)完全不同，它的哲学是:
Python is a great scripting language. Don't reinvent the wheel...your templates can handle it !
作为一个 Pythoner，我完全赞同，Jinja 也被我无情的抛弃了。
综上看来，Mako 才是我的首选，不过问题又来了。经过我观察，在 CGI 中，模板的替换以及结果输出这两部分功能所消耗时间占整个 CGI 处理时间的比重非常的大，通常都占 50% 以上，有的时候甚至更多。我可以优化模板替换部分的效率，但完全没有办法对模板输出部分(IO)的效率进行优化，效率提升空间非常有限。
这的确是很令人沮丧的事。不过我想如果要是有一种 Javascript 的模板系统的话，应该可以解决上面的问题。
于是，借助伟大的 Google， 我又找到了 JST(from trimpath), 它的基本原理是将模板系统转换为实际的 Javascript 代码，和Jinja 的原理类似，只是它是在客户端实现的，生成的是 Javascript 代码而已。不过它的缺点是，模板解析是在客户端进行的，多多少少会影响效率；支持的语法并不太多，和其它的模板系统相比，功能并不算强大，不支持双重循环(可以自己实现)；貌似是我的要求太高了，其实它还是非常优秀非常具有可用性的。
受 Jinja 模板系统的启发，我打算为 Jinja 编写一个 Javascript Translator，可以将模板代码编译为 Javascript 代码。事实上，这是非常可行的，它的官网上也透漏了下一个版本中开发这个 Javascript Translator 的消息。 我很早就开始着手这一 Translator 的编写工作，目前基本可以出一个 demo 了。 Jinja 还是很值得继续关注。
不过我又很快找到了 genshi2js，它可以将 genshi 模板转换为实际 Javascript 代码, 虽然它仅仅支持 xml 格式的模板系统，但我还是很有兴致的试了一试。生成的 js 代码还是非常不错。不过它要依赖一个叫做 MochiKit 的 Js 库，这家伙比较庞大，有 110k 左右(未压缩)，如果可以压缩到 40k 以下的话，还是有一定的可用性的，有待进一步研究。
偶然间，我发现了另外一个 Javascript 模板系统， 他和 Mako 的哲学类似，直接用 Javascript 来写模板的逻辑，它没有名字，因为他实在太小了，仅仅有30行左右，Blog 作者仅仅用一篇 blog 对它进行了介绍，跟贴者无一不说 cool，它就是我想要的。
我找到了理想中的模板系统。
我一直在搜寻一种模板系统，它的速度要快，功能要强，用起来要比较简单。
一开始，我找到了 django 模板系统。和同类模板系统相比，它的速度是最快的，当然比用 C 写的模板系统稍慢一点，但已经非常不错；功能当然非常强，你甚至可以自己定义语法；用起来确实也非常简单。
但我也有追求效率的毛病，如果存在和 Django 模板系统类似，但比 Django 模板效率更高的模板系统，我会马上移情别恋。
这时，我发现了 Jinja 模板系统，它拥有 Django 模板系统的语法，并且具有更高的执行效率。原因很简单，它将模板代码转换成了可执行的 python 代码，并且有相应的 Cache 策略，速度自然要快很多。
Jinja 系统已经非常不错，但可惜的是，我又发现了 Mako 模板系统，它直接用 Python 代码来书写模板里面的逻辑，和前两种模板系统的哲学(Philosophy)完全不同，它的哲学是:
Python is a great scripting language. Don't reinvent the wheel...your templates can handle it !
作为一个 Pythoner，我完全赞同，Jinja 也被我无情的抛弃了。
综上看来，Mako 才是我的首选，不过问题又来了。经过我观察，在 CGI 中，模板的替换以及结果输出这两部分功能所消耗时间占整个 CGI 处理时间的比重非常的大，通常都占 50% 以上，有的时候甚至更多。我可以优化模板替换部分的效率，但完全没有办法对模板输出部分(IO)的效率进行优化，效率提升空间非常有限。
这的确是很令人沮丧的事。不过我想如果要是有一种 Javascript 的模板系统的话，应该可以解决上面的问题。
于是，借助伟大的 Google， 我又找到了 JST(from trimpath), 它的基本原理是将模板系统转换为实际的 Javascript 代码，和Jinja 的原理类似，只是它是在客户端实现的，生成的是 Javascript 代码而已。不过它的缺点是，模板解析是在客户端进行的，多多少少会影响效率；支持的语法并不太多，和其它的模板系统相比，功能并不算强大，不支持双重循环(可以自己实现)；貌似是我的要求太高了，其实它还是非常优秀非常具有可用性的。
受 Jinja 模板系统的启发，我打算为 Jinja 编写一个 Javascript Translator，可以将模板代码编译为 Javascript 代码。事实上，这是非常可行的，它的官网上也透漏了下一个版本中开发这个 Javascript Translator 的消息。 我很早就开始着手这一 Translator 的编写工作，目前基本可以出一个 demo 了。 Jinja 还是很值得继续关注。
不过我又很快找到了 genshi2js，它可以将 genshi 模板转换为实际 Javascript 代码, 虽然它仅仅支持 xml 格式的模板系统，但我还是很有兴致的试了一试。生成的 js 代码还是非常不错。不过它要依赖一个叫做 MochiKit 的 Js 库，这家伙比较庞大，有 110k 左右(未压缩)，如果可以压缩到 40k 以下的话，还是有一定的可用性的，有待进一步研究。
偶然间，我发现了另外一个 Javascript 模板系统， 他和 Mako 的哲学类似，直接用 Javascript 来写模板的逻辑，它没有名字，因为他实在太小了，仅仅有30行左右，Blog 作者仅仅用一篇 blog 对它进行了介绍，跟贴者无一不说 cool，它就是我想要的。
我找到了理想中的模板系统。
我选择 mootools
2007-9-7 17:38:00 阅读426 评论6 72007/09 Sept7
近来对 Ajax 方面的关注比较多，搞 Web 开发的嘛，如果不了解 Ajax 、CSS 是会被人耻笑的，不是一个合格的 Web 开发人员；可惜的是组内一直没有大规模用 Ajax 的项目，实践的机会也比较少；并且大部分人对 Ajax 还仅仅停留在尝鲜阶段，或者压根就排斥这些东西，学习氛围并不是很好。
在开始 Ajax 项目之前，要先选择一个适合的 FrameWork，这样我们的开发会稍微轻松一些，少走很多弯路。眼下 JavaScript 的 FrameWork 可真不少，主要了解过的有 Jquery、Dojo、Yui、Ext、Prototype、Mootools、Njf等，其它未提及的都不在考虑之列。
其中 Dojo、Yui、Ext这三个，下载下来之后就直接被我枪毙了，没有仔细看过，也没有兴趣看；他们的特点是，体积不一般的大，文件不一般的多，大部分文件的代码量都是浩浩荡荡数千行；我被吓住了，我知道我的需求，我不需要这些东西。
用的最多的当属 Njf 了，现在项目中能用到 Ajax 效果的地方真不多，最多不过是动态生成某些元素、层的显示与隐藏、元素的漂移、简单的事件的处理等，比较简单，用 Njf 足够了。Njf 是神崴之做，代码短小精悍，质量更是没得说，看着舒心，用着放心。
不过 Njf 有一个缺点，或者是 Njf 的哲学，它提供的功能太少；一些很普通的功能它都没有，需要你自己来实现，其实网上的代码很多，直接拿过来就可以用了，但是总有一点不爽，这种情况比较多时会令人非常难受；所以，在比较复杂的场合，它也不是最好的选择。
Jquery 和 Prototype 这两个库仅仅是了解了一下，并没有用于实际项目。从他们功能上看，JQuery 更偏向于表现层,而且它与 CSS结合是如此地紧密，以至于可以很方便地控制页面元素；而 Prototype 则更像是 js 的补充功能库；当然二者是有交叉的，只是侧重点不同。
从我个人的理解来看，JQuery 有点走错了方向，Js FrameWork 不应该过分关注表现层的东西，否则会死的很惨；另外在浏览它的代码的时候，发现了两个爆长的函数（估计超过200行），对它的印象大大折扣；Jquery1.1.3 发布的时候，听说速度提升 800%，暴寒，它过去就有那么差吗？
Prototype 非常不错，不过它的代码有 3 千多行，注释非常匮乏，结构显的并不是太清晰，所以读起来也比较头大；虽然如此，在我未发现 Mootools 之前，它仍然是我的首选。
认识 Mootools 是最近的几天的事，在逛 JavaEye 时偶然发现的，当时某位牛人像寻到宝贝一样发了一个标题为强烈推荐 mootools 替代 prototype的文章(文章2)，稍稍关注了下，我就一发不可收拾的爱上它了。
它是一个简洁、模块化、面向对象的 JavaScript 框架。代码结构非常清晰，很具可读性，注释非常全面，有非常完整的文档和特效示例；虽然它也有数千行的代码，但你仍然可以不费力气非常轻松的读懂它。
它与 Prototype 类似，但在模块化方面它要比 Prototype 好很多，功能也要强大很多；
它的下载页面更是酷的要命，你可以选择你要下载的模块和压缩的选项，它会自动的把那些模块合并成一个文件提供给你。
更多功能，请到它的官网了解吧。
所以，我选择了mootools，也强烈建议大家尝试下 Mootools 。
在开始 Ajax 项目之前，要先选择一个适合的 FrameWork，这样我们的开发会稍微轻松一些，少走很多弯路。眼下 JavaScript 的 FrameWork 可真不少，主要了解过的有 Jquery、Dojo、Yui、Ext、Prototype、Mootools、Njf等，其它未提及的都不在考虑之列。
其中 Dojo、Yui、Ext这三个，下载下来之后就直接被我枪毙了，没有仔细看过，也没有兴趣看；他们的特点是，体积不一般的大，文件不一般的多，大部分文件的代码量都是浩浩荡荡数千行；我被吓住了，我知道我的需求，我不需要这些东西。
用的最多的当属 Njf 了，现在项目中能用到 Ajax 效果的地方真不多，最多不过是动态生成某些元素、层的显示与隐藏、元素的漂移、简单的事件的处理等，比较简单，用 Njf 足够了。Njf 是神崴之做，代码短小精悍，质量更是没得说，看着舒心，用着放心。
不过 Njf 有一个缺点，或者是 Njf 的哲学，它提供的功能太少；一些很普通的功能它都没有，需要你自己来实现，其实网上的代码很多，直接拿过来就可以用了，但是总有一点不爽，这种情况比较多时会令人非常难受；所以，在比较复杂的场合，它也不是最好的选择。
Jquery 和 Prototype 这两个库仅仅是了解了一下，并没有用于实际项目。从他们功能上看，JQuery 更偏向于表现层,而且它与 CSS结合是如此地紧密，以至于可以很方便地控制页面元素；而 Prototype 则更像是 js 的补充功能库；当然二者是有交叉的，只是侧重点不同。
从我个人的理解来看，JQuery 有点走错了方向，Js FrameWork 不应该过分关注表现层的东西，否则会死的很惨；另外在浏览它的代码的时候，发现了两个爆长的函数（估计超过200行），对它的印象大大折扣；Jquery1.1.3 发布的时候，听说速度提升 800%，暴寒，它过去就有那么差吗？
Prototype 非常不错，不过它的代码有 3 千多行，注释非常匮乏，结构显的并不是太清晰，所以读起来也比较头大；虽然如此，在我未发现 Mootools 之前，它仍然是我的首选。
认识 Mootools 是最近的几天的事，在逛 JavaEye 时偶然发现的，当时某位牛人像寻到宝贝一样发了一个标题为强烈推荐 mootools 替代 prototype的文章(文章2)，稍稍关注了下，我就一发不可收拾的爱上它了。
它是一个简洁、模块化、面向对象的 JavaScript 框架。代码结构非常清晰，很具可读性，注释非常全面，有非常完整的文档和特效示例；虽然它也有数千行的代码，但你仍然可以不费力气非常轻松的读懂它。
它与 Prototype 类似，但在模块化方面它要比 Prototype 好很多，功能也要强大很多；
它的下载页面更是酷的要命，你可以选择你要下载的模块和压缩的选项，它会自动的把那些模块合并成一个文件提供给你。
更多功能，请到它的官网了解吧。
所以，我选择了mootools，也强烈建议大家尝试下 Mootools 。
天气
模块内容加载中...