最近研究了一下JdonFramework,有些问题。

1、研究了一下JF的PageIterator机制,的确不错。好像第一次加载的时候会全部读取数据库中的记录,如果表有n多记录就会很慢。自己改了一下源码,做了一次自动封装类似mysql的limit。这样在200条记录以内就不用获取,超过block大小后在自动limit下一个block的id回来。不知道有问题,因为改的代码比较少。因为我想banq一开始应该意识到这个问题。

2、然后就是cacheManager机制,如果我一开始就定义了一个cacheManager容器,那么所有JF中使用cache的地方都回使用同一个cache容器。包括ModelCacheManager也是。如果我在JF框架中定义了多个表的Model,感觉在管理ModelCacheManager时会有冲突。比如我的两个表都是一条主键id=1的记录,删除cache时是调用,CacheKeyFactory.getAllCacheKey找cache的key

public Collection getAllCacheKey(Object dataKey){
if (dataKey == null ) return null;
if (dataKey.toString() == null) return null;

String cacheKey = null;
String dataTmpKey = null;
Collection list = new ArrayList();

Map map = cacheManager.getCacheKeyMap();
Iterator iter = map.keySet().iterator();
while(iter.hasNext()){
cacheKey = (String)iter.next();
dataTmpKey = (String)map.get(cacheKey);
System.out.println("CacheKeyFactory: cacheKey="+cacheKey+"\tdataTmpKey="+dataTmpKey);
if (dataTmpKey.equals(dataKey.toString())){
list.add(cacheKey);
}
}
return list;
}

其中参数 dataKey 是主键id=1的值。循环中:cacheKey 的值是{Model+类名}
dataTmpKey 是值“1”,这样如果删除Model时由于使用了同一个CacheManager所以造成会找Model时会找出其他相同的值的Model的cache,然后del了。不知道是不是这里的颗粒度比较粗,或者我使用的方法不对。

3、好像一个组件类不能被实例化多个。如:
<component name="cacheManager" class="com.jdon.controller.cache.CacheManager" />
<component name="cacheManager2" class="com.jdon.controller.cache.CacheManager" >
<constructor value="test.Cache" />
</component>
不知道我想这种怎么实现?

希望能一起讨论一下。JF很不错,支持!


[该贴被wangcy于2008-03-07 19:56修改过]

>超过block大小后在自动limit下一个block的id回来
JF的PageIterator就是这样实现的,只要你直接使用就可以了。

>如果删除Model时由于使用了同一个CacheManager所以造成会找Model时会找出其他相同的值的Model的cache,然后del了。不知道是不是这里的颗粒度比较粗,

是这样的,这样删除更新的粒度不算粗了。当然也可以再精确一下,粒度越细,性能总会有些影响,所以,当时就到这里"适"可而止了。

>好像一个组件类不能被实例化多个
组件一旦注册到JF容器中,都是单例形式,如果你喜欢多态,可以通过原型模式,比如使用clone,或通过构造器new手工实现。

多谢 楼主对JF肯定,从楼主问题中,也看出楼主是一位具有实战经验的高手,JF这样的框架能被楼主这样的专业人士赏识,也是Jdon的荣幸啊,如果使用研究有什么问题,欢迎在这里交流,共同提高。

多谢banq!
通过几天的研究,大概已经看懂了整个机制。
由于想在项目中尝试JF,所以做了很多测试。包括对cache的整个研究,需要做一些调整来适合群集服务处理。比如增加了memcached作为cache容器,同时也把session做了一个memcached的拦截器,但是由于memcached需要做序列化。VisitorFactory使用了session容器,所以也尝试把VisitorFactory做成了一个接口,用Ehcache做容器。

由于JF核心还是IOC和AOP,所以尝试了一下升级,把picocontainer升级到了1.3,2.0还没有测试,准备过几天测试一下。直接用1.3的CachingPicoContainer代替了JdonPicoContainer,由于比较懒就没有做太多测试。不过程序没有报错,通过压力测试感觉速度差不多,感觉好像快点,不过等有空在继续压一下。

为了适合自己将要做的应用改了一些地方,不过的确在JF继续上省事不少。不过也需要重新写好多特定的基础类来支持我的需求。

继续关注中。。。。
[该贴被wangcy于2008-03-09 01:18修改过]

行家伸伸手,便知有没有。

>VisitorFactory使用了session容器,所以也尝试把VisitorFactory做成了一个接口,用Ehcache做容器。

这就是我当初费尽心思使用访问者模式的原因所在,可以使得Session容器能够替换,缺省是使用Servlet容器的Session来实现访问,你可以自己做一个VisitorFactory实现之类,使用Ehcache来实现Sessionh

>不过也需要重新写好多特定的基础类来支持我的需求。
如果你能详细说说你的需求,也许我能帮你策划设计讨论一下,帮助你整理思路

不太理解session容器和Ehcache做容器。
使用Servlet容器的Session来实现访问是为每个请求在内存中放一份HttpSessionProxyVisitor吗?
如果以后Ehcache容器替换是否意味着不具备session性质而是所有的请求共享?

Ehcache只是一个缓存容器,它的使用生命周期还是需要你来配置,如果scope配置成applicaion就是一个全局缓存,如果配置成session,就是session缓存了