最近研究了一下 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对象状态管理机制的 ...
firebody
搜索本博客
最近加入圈子
存档
最新评论