日期:2014-05-16  浏览次数:20482 次

FreyjaJdbcTemplate 大致上完工了,想请人重构。。

最后一个功能动态update完成,freyja还需要稳定性测试,并且检查疏漏的地方。

?

我对freyja的这套想法还是很满意的,cache就是几个map。不需要序列化。

执行update方法的时候维护缓存。

如何在当前方法里面知道是否开启了事物?如何知道几个方法是否在同一个事物里面?

我没有找到相关的API方法,但是根据同一个事物会共用一个连接来判断是否在同一个事物里面。

然后根据“事物缓存”来比较update了哪些字段。"List<String> updateColumn = MethodUtil.beanMapping(oldValue, value);"

?

由此就可以动态update,而不需要每次update的时候update整条记录。也许这样能提升update性能。

但是动态update由可以提高维护缓存的效率。因为如果一次update整个记录和update单个字段是不同的。

?

代码现在很乱,乱得我自己焦头烂额的。还希望有达人能帮忙重构一次。

?

----

整个程序是这样的,初始化的时候会扫描bean。把一些映射信息存到BeanInfoCache的map里面。

get(T)就是直接使用jdbctemplate的query

save(T)也是直接使用jdbctemplate的update

update(T) 就是用上面说的动态update 然后拼接sql,动态还是很有必要的,上面说明了。

?

executeUpdate(HQL)首先直接发送sql update数据库。然后处理缓存:

分为2类,一类是可以直接在内存中查找出来的。还有一类是没办法查出来的,这部分通过发送sql得到 ID然后得到结果集。

?

查出来了内存中需要更新的实体之后,通过

"private <T> void update(T t, BeanInfo<?> bi, Update update, Object[] args)"方法在内存中通过表达式、反射更新实体。

每个实体更新之后还需要更新查询缓存:

"private <T> void updateQueryCache(BeanInfo<?> bi, T t, boolean remove,List<String> columns)"

?

更新查询缓存的逻辑还算简单,上一篇应该大致上讲过了。只不过加了动态update,可以缩小更新范围。

?

?

?

放入查询缓存这块:"public List find(Integer first, Integer max, String hql, int type,Object... args)"

这个方法也是find主方法。

?

HQL分为支持查询缓存和不支持查询缓存2部分。判断支持的条件在解析HQL的时候已经知道了。

然后支持查询缓存的这部分还分为查询全部和查询部分。

区别在于查询部分在查询全部的基础上还需要处理一次:

"list = SqlParser.parser(list, sis, hm.bi, hm.rowMapperType)"

这样得到最终需要的查询结果。

QuertyResult

?

?

public List list;

public List result;

?

?

result才是实际的结果集。

list为该结果集涉及到的数据库记录。这个用于维护缓存的时候进行逻辑判断。

?

放入查询缓存这部分还需要改,但是还没想到更好的方法。

?

事物这块直接把spring的copy过来,在commit的地方加了释放“事物缓存”。

?

虽然到处都用到了反射,但是这个不觉得是问题。不知道还有哪些漏掉的东西。

?

本想看看hibernate是怎么实现动态update,但是在hibernate的源码里面迷失了。看到saveOrUpdate监听器这块就跟丢了

还希望有人能帮帮忙,谢谢!

?

下面有测试用项目,里面包含需要的代码。lib包就在前面几篇有放出下载。

?

?

1 楼 osprey 2011-12-11  
lz这个东东不知道是用来干什么的,如果纯粹练手,无所谓,如果是为了用,为了所谓的缓存性能,又放弃了事务的原子性,又要手工干预,搞的一个update,程序员要配一堆东西,而且得时刻牢记,否则一旦需求改了,忘了改这里的配置,调试时第一次对的,后面一次错误的,出了与预期不符的东西都不知道怎么死的.
作为一个有生命力的工具或者框架,它最起码符合下面的条件:
1.便于开发,hibernate和ibaits都提供个相关的配置工具或者自动生成的dao层.减轻的开发者的负担.
2.便于调试,方便的知道结果,hibernate提供了hql调试工具,ibatis的sql可以直接在sql的ide上调试
3.符合实际使用环境的场景需要.
4.相当的单元测试及代码覆盖率

你的东东为了片面的增强缓存性能,而放弃了分布式,数据更新的原子性。它的使用场景是什么哪?大型的系统用的是分布式缓存解决数据同步更新问题。小型系统好像也没有场景需要所谓的再次查询的高速缓存。
请搞清楚自己的东东的使用场景再动手设计。

另外,你是否忘了jvm的内存也是有限的,一个hashmap会不会放的东西太多而是jvm out of memory哪? 你也是否忘了实际使用时,你是处在多线程环境下(不要认为在web工程中看不到threads 就认为它不是多线程调用的),线程安全在哪里?单元测试代码在哪里,覆盖率多少?。。。。
好好看看其他比较流行的框架的代码,它们都会面临不少工程上的问题,而不是纯粹的算法问题。为了纯粹的高性能,我一般都使用内存数据库,然后由内存数据库与主库同步,而无需代码干预。
2 楼 aa87963014 2011-12-11  
支持部支持事务 其实无所谓。我正在准备小改一下,这样就跟其他的orm差不多了

freyja里面支持原生sql的。
如:select uid from User
select user_id from t_user

这个表达的意思是一样的所以都支持。直接写sql

线程安全应该没问题,没有共享变量。其他的还在改,

事情有点多所以测试还不够完善,但是这个毕竟不成问题。再说我也没指望一出来就能让别人替换掉hibernate之类的orm框架。
谢谢你的支持。
3 楼 aa87963014 2011-12-11  
缓存都是交给ehcache管理的。等支持事务之后随便你分布式还是怎么都行。

开始不支持事务是因为 本身如果去掉事务的支持对程序的并发性能是有巨大的提升的。
再则每次都去取》序列化》存》序列化,在你不需要分布式的情况下本身是无谓的操作。
4 楼 osprey 2011-12-11