mysql数据迁移到oracle，其中有个表名叫“bil_vip”，有10万条记录，迁移后检查发现oracle数据库只插入34464条记录，程序执行过程没有发现任何错误。修改数据库连接代码向mysql插入10万条记录，结果都插入OK。

批量插入使用spring jdbctemplate.batchUpdate(sql, new BatchPreparedStatementSetter());方法，该方法的核心是PreparedStatement的executeBatch方法。

2.   继续实验：

新建一个Test表，只有一个name字段做实验。

抛弃jdbctemplate，直接使用PreparedStatement做实验，结果和jdbcTemplate是一样的，实验证明总是会丢失65536条记录。

oracle 驱动的问题？换了最新driver，还是不行。继续探索....

3.   希望之光：

早上发了个消息向大家征求思路，继中说了一句分批处理，点亮了我的思路。按照继中提供思路，每1万条记录一批，分多批发送给Oracle。

结果喜出望外，10万条记录全部插入成功。但是"65536"这个数字是什么意思呢......     

在网上搜索文章发现，这个65536是一个bug。当PreparedStatement批量处理正好65536个记录时候，程序会挂死。我试了一下真的挂死了，太吓人了，这坑够深的。

4.   解决方案：

spring jdbctemplate还是很好用的，而且业务已经被我封装了，如果使用PreparedStatement意味着多了一个处理分支，以后维护会很麻烦。

我新建一个MyJdbcTemplate类，继承 jdbctemplate类，并覆盖了batchUpdate方法。这下舒服了，系统又恢复了整洁。      

5.   ★ 结论和收获：

ü  有事多思考，多请教身边同事。

ü  坚持Open-close原则(Open for extension, Closed for modification)会系统更好的扩展，非常容易维护，关键是要坚持这个原则，如果我因为一个特殊分支使用了PreparedStatement，这样势必破坏了这个原则，日后的维护必然会很麻烦。

ü  基于oracle数据如果使用jdbc批量，一定要分批发送数据oracle，否则正好发一个65536系统就挂死，大于65536数据就丢失，杯具呀......

6.   题目何以为“血案”：

周二打球回家就想这个问题，打开笔记本调试，不知不觉搞到很晚，影响媳妇睡觉（媳妇早上5:30上班），被痛骂一顿，赶紧上床睡觉，我媳妇气的不行，手痛砸了一下床板（我们的床撤掉了床垫，只有床架和木板），床一下子塌了，把媳妇吓坏了，把我腿弄伤了一块，唉，“血案”呀。

一、     概念

Commons-logging : apache最早提供的日志的门面接口。避免和具体的日志方案直接耦合。类似于JDBC 的api 接口，具体的的JDBC driver 实现由各数据库提供商实现。通过统一接口解耦，不过其内部也实现了一些简单日志方案。

Log4j : 经典的一种日志解决方案。内部把日志系统抽象封装成Logger 、appender 、pattern 等实现。我们可以通过配置文件轻松的实现日志系统的管理和多样化配置。

Slf4j : 全称为Simple Logging Facade for JAVA：java简单日志门面。是对不同日志框架提供的一个门面封装。可以在部署的时候不修改任何配置即可接入一种日志实现方案。和commons-loging 应该有一样的初衷。个人感觉设从计上更好一些，没有commons 那么多潜规则。同时有两个额外特点：

1. 能支持多个参数，并通过{} 占位符进行替换，避免老写logger.isXXXEnabled 这种无奈的判断，带来性能提升见：http://www.slf4j.org/faq.html#logging_performance 。

2.OSGI 机制更好兼容支持

一图胜千言，官网上的一个图：

 

从上图可以发现，选择还是很多的。

Logback : LOGBack 作为一个通用可靠、快速灵活的日志框架，将作为Log4j 的替代和SLF4J 组成新的日志系统的完整实现。官网上称具有极佳的性能，在关键路径上执行速度是log4j 的10 倍，且内存消耗更少。具体优势见：

http://logback.qos.ch/reasonsToSwitch.html

二、     常见日志方案和注意事项

1.Commons-logging+log4j : 经典的一个日志实现方案。出现在各种框架里。如spring 、webx 、ibatis 等等。直接使用log4j 即可满足我们的日志方案。但是一般为了避免直接依赖具体的日志实现，一般都是结合commons-logging 来实现。常见代码如下：

import org.apache.commons.logging.Log;

import org.apache.commons.logging.LogFactory;

private static Log logger = LogFactory.getLog(CommonsLoggingTest.class);

代码上，没有依赖任何的log4j 内部的类。那么log4j 是如何被装载的？

Log 是一个接口声明。LogFactory 的内部会去装载具体的日志系统，并获得实现该Log 接口的实现类。而内部有一个Log4JLogger 实现类对Log 接口同时内部提供了对log4j logger 的代理。LogFactory 内部装载日志系统流程：

1.   首先，寻找org.apache.commons.logging.LogFactory 属性配置

2.   否则，利用JDK1.3 开始提供的service 发现机制，会扫描classpah 下的META-INF/services/org.apache.commons.logging.LogFactory 文件，若找到则装载里面的配置，使用里面的配置。

3.   否则，从Classpath 里寻找commons-logging.properties ，找到则根据里面的配置加载。

4.   否则，使用默认的配置：如果能找到Log4j 则默认使用log4j 实现，如果没有则使用JDK14Logger 实现，再没有则使用commons-logging 内部提供的SimpleLog 实现。

从上述加载流程来看，如果没有做任何配置，只要引入了log4j 并在classpath 配置了log4j.xml ，则commons-logging 就会使log4j 使用正常，而代码里不需要依赖任何log4j 的代码。

2.Commons-logging+log4j+slf4j

如果在原有commons-logging 系统里，如果要迁移到slf4j, 使用slf4j 替换commons-logging ，也是可以做到的。原理使用到了上述commons-logging 加载的第二点。需要引入Org.slf4j.jcl-over-slf4j-1.5.6.jar 。这个jar 包提供了一个桥接，让底层实现是基于slf4j 。原理是在该jar 包里存放了配置META-INF/services/org.apache.commons.logging.LogFactory =org.apache.commons.logging.impl.SLF4JLogFactory ，而commons-logging 在初始化的时候会找到这个serviceId ，并把它作为LogFactory 。

完成桥接后，那么那么简单日志门面SLF4J 内部又是如何来装载合适的log 呢？

原理是SLF4J 会在编译时会绑定import org.slf4j.impl.StaticLoggerBinder; 该类里面实现对具体日志方案的绑定接入。任何一种基于slf4j 的实现都要有一个这个类。如：

org.slf4j.slf4j-log4j12-1.5.6: 提供对 log4j 的一种适配实现。

Org.slf4j.slf4j-simple-1.5.6: 是一种 simple 实现，会将 log 直接打到控制台。

……

那么这个地方就要注意了：如果有任意两个实现slf4j 的包同时出现，那就有可能酿就悲剧，你可能会发现日志不见了、或都打到控制台了。原因是这两个jar 包里都有各自的org.slf4j.impl.StaticLoggerBinder ，编译时候绑定的是哪个是不确定的。这个地方要特别注意！！出现过几次因为这个导致日志错乱的问题。

3.Slf4j+logback

Slf4j 和log4j 作者都是同一个人。

Logback 号称在性能各方面有很多优势，也很诱人。

直接使用SLf4j 也很简单：

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
  public static void main(String[] args) {
    Logger logger = LoggerFactory.getLogger(HelloWorld.class);
    logger.info("Hello World");
  }
}

代码里也看不到任何具体日志实现方案的痕迹。

Logback 没用过，看到过一些诱人介绍。具体大家可以去研究。logback 。

注意事项

使用日志配置的时候一定要明白需求，同时避免冲突。

如使用SLF4j 的时候为了避免冲突，一定要保障只有一种实现类jar 包在里面。

当遇到日志错乱等问题时，可以从这几个方面来排查

webapp

  ├─META-INF

  └─WEB-INF

               ├─ftl/    (freemaker模板文件)
               ├─lib/sitemesh-2.4.1.jar
               ├─decorators.xml
               └─web.xml       

3、decorators.xml内容如下：

<decorators>
</decorators>
(Optional) Create the file [web-app]/WEB-INF/sitemesh.xml that contains the following:
<sitemesh>
    <property name="decorators-file" value="/WEB-INF/decorators.xml" />
    <excludes file="${decorators-file}" />

    <page-parsers>
        <parser content-type="text/html"
            class="com.opensymphony.module.sitemesh.parser.HTMLPageParser" />
        <parser content-type="text/html;charset=ISO-8859-1"
            class="com.opensymphony.module.sitemesh.parser.HTMLPageParser" />
    </page-parsers>

    <decorator-mappers>
        <mapper class="com.opensymphony.module.sitemesh.mapper.ConfigDecoratorMapper">
            <param name="config" value="${decorators-file}" />
        </mapper>
    </decorator-mappers>
</sitemesh>

4、修改web.xml 文件如下：

<filter>
    <filter-name>sitemesh</filter-name>
    <filter-class>com.opensymphony.sitemesh.webapp.SiteMeshFilter</filter-class>
</filter>

<filter-mapping>
    <filter-name>sitemesh</filter-name>
    <url-pattern>/*</url-pattern>
</filter-mapping>

That's it! Your web-app is now setup to use SiteMesh, you can now start building decorators.