今天Bruce问我spring怎么样，我的感觉主要是：

• 可以用配置文件组装系统，使得系统很灵活，可以在不修改原有代码的情况下扩充功能或者替换某个实现
• 可以使用声明式事务
• 使用使用spring提供的模板简化代码
• 可以使用spring提供的其它很多功能简化代码
• 可以使用AOP

但是：Spring不是必须的。
对于小项目，引入spring可能反到增加不必要的复杂性，毕竟spring也是需要很多配置的，有时候就没有一个new来得简单，而且使用spring后很多错误要到运行的时候才能发现，而修改配置已经来不及了，只能重启 web服务器。
（在spring的配置太多的时候，启动好像很慢，这个是因为要预先初始化很多类并组装好）

但是总体上感觉spring是个好东西，在以后的项目中要尽量使用。

最后推荐：疑惑：为什么要用Spring？以及简化Spring

bruce说我的那个得到GMT时间的
代码是错误的，和他讨论了很长时间，后来发现果然是我的理论方面有问题，就java.util.Date类的定义而言，它本来就是当前的GMT时间相对于
1970年1月1日的GMT时间的long值，但是如果使用System.out.println()等方法打印出其内容的时候，也就是使用
Date.toString方法的时候，我们看到的是经过时区修正的结果，这个看看java.util.Date的实现就可以知道：

    public String toString() {
	DateFormat formatter = null;
	if (simpleFormatter != null) {
	    formatter = (DateFormat)simpleFormatter.get();
	}
	if (formatter == null) {
	    /* No cache yet, or cached formatter GC'd */
	    formatter = new SimpleDateFormat("EEE MMM dd HH:mm:ss zzz yyyy",
					     Locale.US);
	    simpleFormatter = new SoftReference(formatter);
	}
        synchronized (formatter) {
            formatter.setTimeZone(TimeZone.getDefault());
            return formatter.format(this);
        }
    }

从代码我们可以看到是使用时区格式化的结果（JDK5的代码和这个不同）。
问题是：当我们将这个GMT的Date值转换到java.sql.Date或者java.sql.Timestamp存到数据库里面以后，数据库里面的值
是我们的本地时间而不是GMT时间，因此，如果你需要数据库存储GMT时间的时候，还是需要使用我的那个方法进行转换。至于为什么要存储GMT时间，这个
是有跨时区应用的时候要考虑的问题，例如一个系统中国的用户和美国的用户同时使用，否则时间会很混乱。

本来以为得到GMT时间很简单，通过Calendar 
date = Calendar.getInstance(TimeZone.getTimeZone(“GMT”));然后
date.getTime()就是，但是实际的结果不是，要得到GMT时间还是需要转换下的，以下是得到当前的GMT时间：
    public static Date getGMTDate ()
    {
        Calendar calendar = Calendar.getInstance();
        int offset = calendar.get(Calendar.ZONE_OFFSET)/3600000 +
               
calendar.get(Calendar.DST_OFFSET)/3600000;
        calendar.add(Calendar.HOUR,-offset);
        return calendar.getTime();
    }

做了一个简单的项目，使用到了spring和hibernate，但是有一个很奇怪的现象，就是运行很慢，从最简单的登陆开始就很慢，跟踪了一下，竟然花
了20多秒，然后把里面的一个update操作注释掉后就快了很多，一般不到一秒了，但是下一个操作也很慢了。最开始是怀疑更新数据库导致的缓存的性能问
题，但是后来去掉缓存问题依旧，然后继续跟踪，发现有个get操作也很慢，而get方法体内的操作实际也是很快的，也是不到一秒，怀疑是spring封装
的HibernateTemplate的问题，但是仔细一想不太可能，这个应该是有很多人用过了，而且以spring的技术能力应该不会有这种问题。突然
想到我的这些DAO方法都是配置了声明式事务的，而事务对性能的影响实际上是很大的，原来的配置如下：
        <property name=”transactionAttributes”>
            <props>
           
    <prop
key=”insert*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”update*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”delete*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”get*”>PROPAGATION_REQUIRED,readOnly</prop>
            </props>
        </property>

回忆了一下，我的DAO里面有很多不符合这个方法命名的方法，例如登陆方法本身就是login，还有一些addXxx方法以及isXxx，修改了add方法统一为insert方法，然后修改了声明的内容为：
        <property name=”transactionAttributes”>
            <props>
           
    <prop
key=”insert*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”update*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”delete*”>PROPAGATION_REQUIRED</prop>
           
    <prop
key=”*”>PROPAGATION_REQUIRED,readOnly</prop>
            </props>
        </property>

这样修改后问题得到解决。
需要说一下的是，如果这个里面不配置事务，速度也非常的慢。

今天发现MSN的聊天记录备份有问题，我和一个朋友的聊天记录超过了2M，因此在关闭聊天对话框的时候提示我是删除记录还是保存记录，我选择保存，但是过
一会再聊，然后关闭又提示。原来好像是会把旧的记录改名，然后创建一个新的记录文件，难道是有了就不能工作了？这个BUG也太简单了吧，微软的强大的测试
队伍就是这样的？