只显示主题贴

2008-07-18
全文显示

回复: OSGI好处体现在什么地方？代码组织工具？

OSGi是一种概念，它首先告诉我们，写软件的时候要把职责划分清楚，这是合理划分接口、类、包甚至是服务，组件的基础。 OSGi还有一个比较有用的地方，就是可以控制访问范围，这方面Java本身控制得不够细，比如我某个类只希望供某些指定的类使用，Java是无法做到的（Proptected只能供同包和子类用）。
  • 进入论坛 Java 版
2008-07-18
全文显示

回复: DAO的一个讨论问题

laiseeme 写道一直用一个basedao 不过用的是hibernate，一个通用的dao里面包括了一些基本的查询，添加修改删除等等，各个模块dao继承这个basedao，有这个模块相对个性的查询就写到这里面，通用的查询等等就调用basedao里面的方法 这种做法很好，我一向也是这样用，同时把BaseDAO设计成支持泛型，就更加通用和严谨。当然BaseDAO要是接口，把实现屏蔽起来。
  • 进入论坛 Java 版
2008-07-18
全文显示

回复: DAO的一个讨论问题

sunsong 写道rihoonet 写道DAO模式，我觉得太难用了，表结构一改，好多的地方都要改。 那应该是你没有理解DAO模式的好处，如果你分层分得好，即使表结构修改，你要修改的类也是限定于某一个或者几个层里面，另外一些层次，不受影响。 搂主的想法是对的，其实就是应该在设置一个业务逻辑层 比如Jsp->Action->Bussiness->Dao->PO 同意，其实我在面试的时候也问过很多程序员，他们大多数没有把DAO模式的真正作用和思想讲出来，只是说DAO是个数据访问对象，其实可以查阅一下java.sun.com的Blueprint的J2EE Design Pattern Catal ...
  • 进入论坛 Java 版
2008-07-18
全文显示

回复: 海量数据统计的方法？

能不能仿效Google的做法，让多个线程在多台服务器同时运算，返回最终的结果再合并在一起。云计算
  • 进入论坛 Java 版
2008-07-16
全文显示

回复: 如何减少日志记录占用的系统资源

xly_971223 写道这要看日志对你系统的重要性了，特别重要的业务 如涉及到金钱的当然是跟业务操作放在一个事物里 但大多是的日志没这么重要 异步去写数据库也没什么大不了的。日志丢失的概率应该是很小的，我们真正去跟踪的日志更是很小---系统没出问题谁去看它啊，所以JMS是可行的 由于我现在做的是通用日志组件，是提供给各项目使用的，我无法预知项目是否对日志要求严格，因此我必须提供两种解决方案：一是允许日志以很小的概率丢失的情况；一是不允许日志丢失的情况。第一种完全可以用异步方式（JMS or others...）完成，第二种我希望寻求一种比写数据库效率更高的方式完成，但要保证日志无丢失，则必 ...
  • 进入论坛 Java 版
2008-07-15
全文显示

回复: 如何减少日志记录占用的系统资源

javazhujf 写道如果不在同一事务中的确会出现应用正常提交，而日志确没有写入。如果日志非常重要的话的确是很糟糕。 方案一的缓存我觉得行不通； 方案二的内存数据库应该是不错的选择。 其实我对缓存和内存数据库都不太熟，正在了解，请问为什么觉得缓存行不通呢？现在的缓存框架应该支持灾难恢复啊。而内存数据库也好，缓存也好，要保证能够灾难恢复，本质上还是要写磁盘，可能是通过某些优化和简化算法提高性能，总比写数据库要好吧，毕竟我在本地缓存下来的数据只是临时的，最终还是要写数据库，正如我前面所说的，通过JMS发送到另外一台专门的日志服务器，由它负责日子的持久化，而在JMS答复成功接收日志信息之前，我需 ...
  • 进入论坛 Java 版
2008-07-15
全文显示

回复: 如何减少日志记录占用的系统资源

javazhujf 写道我认为可以采用异步和Buffer的方式，比如有专门负责写日志的线程，这个线程负责从队列中读取到一条条的日志然后进行写操作，而应用只需要把日志放到队列里就可以了。至于如何保证“即只要业务操作被提交，日志信息必须保证被成功记录下来”，因为写日志出错的机会比较小，可以让写日志的线程负责一定要把每一条成功写入，除非发生系统级ERROR。 现在我主要担心的就是系统级的无法预知的ERROR，比如应用程序服务器在提交了业务操作事务之后突然崩溃，日志就丢失了。我现在考虑两种方案：保持业务操作和日志持久化事务一致，但日志持久化不直接写数据库或文件，而是利用现有的一些开源的缓存技术（方案 ...
  • 进入论坛 Java 版
2008-07-15
全文显示

回复: 如何减少日志记录占用的系统资源

javazhujf 写道对于磁盘I/O快的牛X机器来说，写日志不算什么，日志并不会导致系统瓶颈。而且通过设定优先级，在系统真正运行的时候输出的日志也仅是少量的INFO级以上信息。另外写日志的时候也可以通过异步来写，不过你说日志作为事务的一部分，就不能这么做了。 我现在要做的日志组件不同于传统的日志（Log4J、JDK Logging等），这些日志信息不是基于代码级的，而是基于业务级的，所以不存在“级别”（INFO之类）的问题，只要应用程序有需求，就要记录日志。现在问题就在于要保持事务一致的情况下如何降低对应用程序的影响，我曾经做过数据移植程序，发现数据持久化的瓶颈在于写入数据库的时刻，用JD ...
  • 进入论坛 Java 版
2008-07-15
全文显示

如何减少日志记录占用的系统资源

最近我在负责公司各项目的通用日志组件的设计和开发，而各项目组考虑得最多的一个问题是性能问题。抽象来看，日志处理分为：日志收集、日志保存、日志查询、日志分析几个主要部分。日志收集必须由应用程序完成，这部分工作可以使用AOP来减少对应用逻辑的干扰，但问题是：日志收集和日志保存都需要损耗系统资源，让系统变得更慢，某些情况下，对于一些简单的业务操作，日志处理所占用的时间可能比业务操作占用的时间更长。所以，最大限度的减少日志处理对应用程序的性能损耗是日志组件需要解决的一个重要问题。 我曾经想过利用JMS把日志信息发送到另外一台服务器，由专门的日志服务器来负责日志信息的持久化（注：对比日志信息收集逻辑， ...
  • 进入论坛 Java 版
2008-07-10
全文显示

回复: 两个系统,数据导入导出的问题

这种问题我遇到过，我之前是做新旧系统的数据移植，新旧系统的数据结构完全不同，结果是我直接用Java写了一个程序进行数据移植（两个数据库是不同的数据库，MySQL > Oracle），开始为了方便使用Hibernate，后来发现大批量数据处理Hibernate确实是瓶颈，改用JDBC，100万级的数据由2天变成2小时。 注意，转移过程中一定要做数据完整性检查。还有，在转移的时候，可以考虑为源数据库增加临时索引，而把目标数据库的所有索引暂时屏蔽掉，这会大大提高转移效率。
johnnylzb
搜索本博客
博客分类
最近加入圈子
存档
最新评论