最近研究了一下 rails的cache设计,发现其中一些不尽如人意的地方:
* cache expiry 编写繁琐
* 分页缓存的清除,现有cache实现的支持都不是很完善
* 在一次清除大量缓存的时候,脏数据读的问题。
我查阅了一些blog以及相关的文章,从他们的抱怨和设计中得到一些启发,我觉得cache可以做得更好,更智能,更能够减少开发人员的工作量。 下面是我设计思路的一些草稿,如果深入分析,觉得可行的话,就可以动手做他:
* 支持 cache 分组。
* 支持简化的expiry rules
* 适当的设计减少一次清除大量缓存时脏数据读的概率和时间窗
* 仅考虑me ...
rails的fixtures有一个令人讨厌的地方:
fixtures 的数据不会在测试结束后自动清除 ,这样就使得fixtures遗留的数据影响到后来的测试。
相关的争论也持续了很久 ,具体的连接请看 http://dev.rubyonrails.org/ticket/2404
里面的 Rick的patch我在rspec下用了,不见好用,我只能自己搞了一个patch,在rspec的 spec_helper.rb下引入
,解决了这个问题 。
patch主要的思路是: 每次测试setup运行前插入fixture的数据,保证这个插入 fixtures数据的事务和test运行时的事务是同一 ...
http://www.ibm.com/developerworks/cn/websphere/library/techarticles/0401_hanis/hanis.html
IBM developerWorks 中国 : WebSphere : 文档库
http://www.ibm.com/developerworks/cn/views/websphere/articles.jsp?view_by=search&search_by=Portlet
下了一个会议纪要,内容太过粗略,不过大概看了一点设计理念,似乎是
B-Tree+Patricia Tree。
结合了两者优点。
更具体的分析,谁能够给出来?
时空复杂度,IO效率等等。
想对那些“迷惑”于Java ORM框架的J2EE开发人员提一些建议,希望能够对他们
更深入的理解和运用J2EE ORM框架来提速工作有所帮助,这些建议可能显得有些”陈旧“和”肤浅“,
因为最近半年我没有再过多的关注Java ORM,并且也没有继续关注J2EE领域新进展。
在合理的使用Java ORM框架之前,必须要对他们有基本的了解,以下几点是最基本的也应该需要
深刻掌握的基础:
* 关键API接口的深刻理解,并且大致清楚其内部逻辑机制。
* 深刻理解经典对象关系与数据库表schema之间的映射关系,特别是外键的关系。理解为何需要如此建立外键。
* Session对象状态管理机制的 ...
- 浏览: 22313 次
- 性别:


- 详细资料
搜索本博客
最近加入圈子
最新评论
-
谈谈应用ORM框架针对遗留 ...
BaseService extends HibernateDAOSupport? ...
-- by sslaowan -
谁了解Paulo提出的String ...
可以用google scholar
-- by tiantian911 -
关于实现一个rails smart ...
nihongye 写道firebody 写道LRU频繁的话,性能应该会很差 不知 ...
-- by firebody -
关于实现一个rails smart ...
firebody 写道LRU频繁的话,性能应该会很差 不知道这个猜测是从哪里来的 ...
-- by nihongye -
谈谈应用ORM框架针对遗留 ...
我也经常会为了少写一些代码而使用继承,而不是用工具类,这样会在心里上有一种更直观 ...
-- by downpour






评论排行榜