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包就在前面几篇有放出下载。

 

 

评论

8 楼 aa87963014 2011-12-12  

而且关于EMPTY_LIST，并不是查询结果为 null

而是查询结果集中没有元素。这个一般框架都应该是这样处理的。当然，我也有想过像hibernate一样返回空。把freyjaJdbctemplate单独分离开来。怎么封装freyjaJdbctemplate 就不需要我来关心。

水平有限，还请多交流下哈！

7 楼 aa87963014 2011-12-12  

osprey 写道

aa87963014 写道

osprey 写道

使用场景到底是什么？用在哪里？
另外，你的 FreyjaJdbcAccessor 对staic HashMap的 sessionCache put，get操作真的是线程安全吗？

HashMap不是线程安全的，代码改动了不少。我放个最新的出来。

无聊,头痛医头,脚痛医脚
FreyjaJdbcAccessor 里的 static List EMPTY_LIST 看起来好像很不错,在FreyjaJdbcTemplate 中查询为空的时候,将EMPTY_LIST  返出去,但你是否保证外部的调用者对 这个EMPTY_LIST的引用不进行add操作,一旦做了,那下一个调用者就吃药了,因为这时这个EMPTY_LIST 里就多了一个元素了.结果与预期不符.
这个东西就代码质量而言还是玩具,就使用场景而言,lz还是没有没有正面回答.没有使用用途的产品是没有什么意义的,就像有光照才能发光的手电筒,没有使用价值

饿，EMPTY_LIST 我是抄袭hibernate/hibernatetemplate的。一个orm框架能有什么适用场景？非分布式结构应该都没问题（分布式环境下会有什么问题我现在也不太了解）

目前用在GAME服务端。

6 楼 osprey 2011-12-12  

aa87963014 写道

osprey 写道

使用场景到底是什么？用在哪里？
另外，你的 FreyjaJdbcAccessor 对staic HashMap的 sessionCache put，get操作真的是线程安全吗？

HashMap不是线程安全的，代码改动了不少。我放个最新的出来。

无聊,头痛医头,脚痛医脚
FreyjaJdbcAccessor 里的 static List EMPTY_LIST 看起来好像很不错,在FreyjaJdbcTemplate 中查询为空的时候,将EMPTY_LIST  返出去,但你是否保证外部的调用者对 这个EMPTY_LIST的引用不进行add操作,一旦做了,那下一个调用者就吃药了,因为这时这个EMPTY_LIST 里就多了一个元素了.结果与预期不符.
这个东西就代码质量而言还是玩具,就使用场景而言,lz还是没有没有正面回答.没有使用用途的产品是没有什么意义的,就像有光照才能发光的手电筒,没有使用价值

5 楼 aa87963014 2011-12-12  

osprey 写道

使用场景到底是什么？用在哪里？
另外，你的 FreyjaJdbcAccessor 对staic HashMap的 sessionCache put，get操作真的是线程安全吗？

HashMap不是线程安全的，代码改动了不少。我放个最新的出来。

4 楼 osprey 2011-12-11  

使用场景到底是什么？用在哪里？
另外，你的 FreyjaJdbcAccessor 对staic HashMap的 sessionCache put，get操作真的是线程安全吗？

3 楼 aa87963014 2011-12-11  

缓存都是交给ehcache管理的。等支持事务之后随便你分布式还是怎么都行。

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

2 楼 aa87963014 2011-12-11  

支持部支持事务 其实无所谓。我正在准备小改一下，这样就跟其他的orm差不多了

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

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

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

事情有点多所以测试还不够完善，但是这个毕竟不成问题。再说我也没指望一出来就能让别人替换掉hibernate之类的orm框架。
谢谢你的支持。

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 就认为它不是多线程调用的），线程安全在哪里？单元测试代码在哪里，覆盖率多少？。。。。
好好看看其他比较流行的框架的代码，它们都会面临不少工程上的问题，而不是纯粹的算法问题。为了纯粹的高性能，我一般都使用内存数据库，然后由内存数据库与主库同步，而无需代码干预。