wczwcg

wczwcg http://wczwcg.javaeye.com UTF-8 Copyright 2003-2008, JavaEye.com http://blogs.law.harvard.edu/tech/rss JavaEye - 做最棒的软件开发交流社区一个现有EJB系统的性能优化方案 wczwcg 作者: wczwcg 链接：http://wczwcg.javaeye.com/blog/210353 发表时间: 2008年07月02日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

一、问题分析
公司目前维护的一个系统，已经有超过8年的历史。现在遇到严重的性能问题，尤其是查询方面。系统简单介绍如下：
1. 架构：客户端（windows程序）+服务端（J2EE,EJB,Web Service）+数据库（oracle）；
2. 技术特点：
客户端和服务端通过Web Service进行数据传输；
服务端为传统的EJB；
服务端数据采用自行开发的DataSet进行封装，以XML格式返回给客户端；
无DAO对象与领域对象；
无数据缓存机制；
数据库设计严重违背第三范式。

查询经常要从好几个表取数，而且需要将表数据经过复杂的转换（如行列转换）才能得到目标结果，数据量较大，超过5万行。由此产生严重的性能问题，特别是并发访问的情况下。

二、数据库和应用程序服务器的比较
下面列出了本人所了解到的二者分别可以采用的优化方法：
1.数据库
使用存储过程实现查询逻辑，以减少网络交互；
升级数据库服务器硬件。

2.应用程序服务器
使用缓存；
使用分布式、集群应用服务器；
升级应用程序服务器硬件

三、结论
如果系统是按照OO的方式设计，则应用程序服务器上的优化方法自然为首选。但系统没有领域对象，没有DAO对象，全部都采用直接生成SQL语句到数据库取数的方式，数据都用DataSet来封装处理。而DataSet由于实现方式的限制，最多只能包含1万行记录，否则1G的内存就会溢出。而由于使用存储过程实现可以解决减少网络交互、实现分批取数等问题，似乎是最佳的解决方案。

欢迎大家讨论。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Wed, 02 Jul 2008 00:27:07 +0800 http://wczwcg.javaeye.com/blog/210353 http://wczwcg.javaeye.com/blog/210353 Color uml 与 DDD wczwcg 作者: wczwcg 链接：http://wczwcg.javaeye.com/blog/182391 发表时间: 2008年04月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

最近在使用Color uml和DDD方法的时候有些思考，写出来和大家一起讨论一下。

1.二者的领域对象划分存在一些相似之处，如：Color uml中的Party,Thing,Place可以对应到DDD中的实体，Description可以对应到DDD中的值对象，moment-interval差不多也可以对应到DDD的服务类。

2.对于前期需求的收集、分析都可以采用Use Case的方法；

3.Color uml和DDD似乎都是直接从需求分析阶段进行设计，扔掉了传统RUP里面的分析阶段。

4.对于Color uml里面的Role对象一直没有深入的理解清楚，似乎仅仅是对业务过程中的一种描叙，实际设计实现的时候并没有进行处理，或者说可能在系统权限的角色中能找到它。
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Sun, 13 Apr 2008 22:13:49 +0800 http://wczwcg.javaeye.com/blog/182391 http://wczwcg.javaeye.com/blog/182391 项目进度的计划 wczwcg 作者: wczwcg 链接：http://wczwcg.javaeye.com/blog/170963 发表时间: 2008年03月13日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

在敏捷开发过程中，关于项目进度、迭代周期的确定，下面是本人的一些理解和实践：
1.项目开始阶段根据需求功能的初始优先级估计工期，初步的安排迭代计划，估计出项目的总体进度计划；
2.在项目进行过程中，根据需求优先级的调整以及项目进展，不断的更改迭代内容、周期，进而更改项目的总体进度计划；

上面是我目前采用的方法，在项目的进行过程中，迭代、总体进度调整的比较频繁。往往最终的项目进度和开始的估计相差很大，导致最初的进度计划很不准确，参考性不强。这可能是由于我对项目组人员的开发速度总结的不够准确。
另外一种考虑是项目开始不进行整个进度的计划，只是安排首次迭代，每次迭代完成前安排下次迭代的内容，这也是xp里面的方法，但这样无法估计项目的总体计划，而很多时候是需要在项目开始的时候就估计出总体进度计划的。

不知道大家的方法如何？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Thu, 13 Mar 2008 21:41:50 +0800 http://wczwcg.javaeye.com/blog/170963 http://wczwcg.javaeye.com/blog/170963 关于使用Hibernate的任意条件组合查询的实现 wczwcg 作者: wczwcg 链接：http://wczwcg.javaeye.com/blog/114444 发表时间: 2007年08月20日

声明：本文系JavaEye网站发布的原创博客文章，未经作者书面许可，严禁任何网站转载本文，否则必将追究法律责任！

其实没有用orm之前，如果系统分层比较彻底的话，也同样有这个问题。我们崇尚service层不包含数据访问的东西，包括sql语句等。这些都应该是dao层实现。但是很多查询功能都需要能够多条件任意组合查询。这个时候数dao层应该如何支撑？

我的想法是：
1.做一个比较通用的查询功能，比如设计一个参数类，查询条件通过这个参数类传递到dao层。dao负责解析；
2.就是dao层穷举这些所有可能的组合，分别为每一个组合生成一个接口方法。

看到有人在Hibernate中是使用detachedCretira来实现的。在查询端构造好detachedCretira，然后传递到dao去查询。但是这种方法违背了分层思想，而且导致了系统对hibernate的依赖。

不知道有没有更好的方法？
本文的讨论也很精彩，浏览讨论>>

JavaEye推荐

]]> Mon, 20 Aug 2007 22:59:52 +0800 http://wczwcg.javaeye.com/blog/114444 http://wczwcg.javaeye.com/blog/114444