两年的开发经历，对新技术的追逐与否我不敢妄自评论。茶余饭后无聊的思考
基础显然重要，当新事物能为我所用的时候，能快速应对，足以
不可否认，新技术的出现,往往能成就一批热心追逐的人[只是少部分，大部分属于随波逐流的困惑]

2000年 应用服务器年 
       这一年，Java应用服务器的需求成为各大公司的最大利益。谁不希望用“业界标准”来标榜自己呢！
■  BEA公司的繁荣从此开始

2001年 EJB年
       这一年，EJB2.0发布，整个Java业界为之震动，“牵强”的分布式架构，让EJB成了魔术词汇
■  EJB成了高价企业软件的“文凭”。懂不懂EJB成为能不能拿到高薪的关键

2002年 设计模式年
       这一年，大家开始发现EJB真TNND难用，开始发现Java开发需要遵循某种规则，设计模式开始流行，
       J2EE核心模式也应运而生
■   jdon网站借着设计模式的热点一举成名

2003年 Hibernate年
       这一年，大家开始否定EJB，开始采用O/R Mapping，Hibernate迅速流行
■  JavaEye由于颇有预见性的推广普及Hibernate而成为国内Java社区的亮点

2004年 Spring年 
       这一年,EJB3规范和JDO2规范忙着打架，但是真正的主角是Spring，Spring携着IoC和AOP迅速占领J2EE的眼球.
■  《Without EJB》 成为大家背弃EJB2.0的宣言书

2005年 AJAX年
       这一年，大部分时间大家都在反思，或者是学习合适的应用程序架构。伴随着Google的Gmail，
       Google Maps等一系列AJAX应用，一个古老的XMLHTTP组件咸鱼翻身。这个冬天终于找到了主题-AJAX
■  骄傲的程序员回头关注“用户体验”

2006年 XX年？
       这一年，除了成名已久的EJB3.0值得期待，我们还能看到出人意料的新名词吗？
       这一年，将会是更深刻的反思年吗？[用已有的技术集合更完美的“用户体验”]
       这一年，我们将何去何从，我也说不清楚
       你呢？

 Goingmm  2006-02-03

打开hibernate.cfg.xml看看具体的JDBCTransaction 和 JTATransaction 配置：

 11)
 2<property name="hibernate.transaction.factory_class">
 3org.hibernate.transaction.JDBCTransactionFactory
 4</property>
 5
 62)   
 7<property name="hibernate.transaction.factory_class">
 8org.hibernate.transaction.JTATransactionFactory
 9</property>
10

可能你还会问：“除了这两种还有其他的选择吗？到底选择那一种好呢？在一个应用中能混合使用吗？”等等问题

分析和解答：
第一个问题
   可以选择其他的事务管理方式。不过都是JTA的不同实现版本。这个目录下面有罗列出来hibernate-3.0\src\org\hibernate\transaction。比如：

1<property name="hibernate.transaction.manager_lookup_class">
2org.hibernate.transaction.WeblogicTransactionManagerLookup
3</property>
4

第二个问题
   概念事务：事务就是能以整体的原子操作形式完成的一系列操作。

   是不是感觉有些饶口？简单的说，事务 就是一个逻辑工作单元。其中包括一系列的操作。至于事务为什么会产生？有什么基本特性？等等。。这些问题今天不就详细的罗列了。网络上有写得很好的文章。
Hibernate 是JDBC的轻量级封装。他本身并不具备事物管理的能力。事务的管理和调度将委托给JDBC或者JTA去做。

    先说，他默认的事务处理机制[ JDBC Transaction ]，这的确是最简单的处理方式，因为Hibernate只是对JDBC事物做了一层简单
的封装。JDBC事务由Connection管理。事务周期局限于Connection的生命周期之内。在Hibernate中这种事务周期也就局限于一个Session之内。做个比较吧！

Connection conn = …    ;      <---   session = sf.openSession();// 初始化数据库连接，

和setAutoCommit= false;

conn.setAutoCommit(false);     <---   tx = session.beginTransactioin(); 会再次确认setAutoCommit是否是false

调用业务方法                   <---   调用业务方法

conn.commit();                 <---   tx.commit(); (对应左边的两句) 这里很关键，关掉自动commit。自己就必须做commit。否则数据是不会被持久到数据库

conn.setAutoCommit(true);

conn.close();                  <---   session.close();

 

简单吧！如果你对JDBC有了解，看到这里可能会坏笑，NND就这么简单，我也会封装…有兴趣的话可以直接去看看具体的源代码。

 
看看第二种[JTA Transaction]有什么神奇的地方吧！

   JTA 提供了跨Session的事务管理能力。JTA的事务是要容器支持的，即JTS，用来分布式的要求比较多一些，比如像银行这种大系统，处理多个事务源的这些的。
   JTA事务管理则是由JTA容器实现。事务的生命周期完全由容器来维护。容器中可以有很多Connection。按照执行的顺序，因该是串联的一条JDBC Connection事务链。所以JTA的事务周期可以跨多个JDBC Connection的生命周期。在Hibernate中这种事务周期也就可以跨越多个Session。
   所以。JTA事务的Connection不能对事务管理进行干涉。意思就是，假如使用了JTA就不应该再重复调用Hibernate的Transaction功能。这里涉及到一种事务模型（嵌套式事务模型）的问题。这里也不详细的介绍具体的几种事务模型了。在EJB2.0规范里面也不支持这种事务处理模型。
   例如 ：

1class A 有一个方法 savePerson()
2class B 有一个方法 saveAddress()
3// Call A.savePerson() and B.saveAddress() Used JTATransaction
4class C 有一个方法 saveAll() 
5UserTransaction tx = (UserTransaction)(new InitialContext.lookup(“…”))
6A.savePerson();
7B.saveAddress();
8tx.commit();
9

 

那么下面这段代码

1Transaction tx = session.beginTransaction();
2tx.commit();
3

就不能在class A 和 class B 中出现。

原因：session.beginTransaction()也同样执行了InitialContext.lookup方法来获UserTransaction的实例，tx.commit()也同样调用了UserTransaction.commit().这样做就会形成嵌套式的事务。在Hibernate里面是不被允许的。会导致运行期错误。

 

谈到这里，不难看出，他们都有着自己鲜明的特点和基本的联系。回到开头的问题，在实际项目中该选用谁好呢？

这就需要分情况而定了。

1) 如果项目有用到Sessionbean.可能你会疑问？这时候由谁来管理事务呢？

答案：用SessionBean来管理。使用JTA会很方便。因为你完全没有必要去理会Transaction。直接在SessionBean的部署描述符里面声明事务就行了。

2) 自己实现一个Service类，来统一调用持久层的方法。这样也能做到前后台的松耦合。但是这时候你对session和Transaction的处理就需要小心了。如果系统考虑分布式就使用JTA否则就JDBC足夷。但还是有必要考虑系统的升级，变迁什么的。对session和Transaction的处理，最好不要放在DAO里面做。单独实现一个模板类来统一做。具体的原因和做法，以后有时间再写出来。

 

第三个问题

由于SessionFactory是线程安全的，他的创建过程非常复杂，代价极其昂贵。一个应用中最好只有一个SessionFactory。事务管理类型的选择是在SessionFactory的属性里面配置的。这里只能选择一种事务管理方式。

当然，你可以说还有特殊的情况，假如，这个应用需要连接到两台数据库服务器，就必须为他创建另一个SessionFactory。那么就可以选用另一种事务管理方式。表面上看这种情况是可以的。居于两种事务的性能考虑。混和用的意义不是很大。假设这样用+面对考虑不周全的DAO，也违背了设计原则，想想，这样的话，因为数据库的变动，还得回去修改DAO的代码吗？（可能会产生嵌套问题）

所以关于这个问题的结论就是：

在一个SessionFactory中只能选用一种事务管理

面对多个SessionFactory的时候，可以混合用，但是不推荐

2005-11-28 CTU OFFICE GOINGMM

Goingmm 2005-11-28 12:00 发表评论

]]>

   
  Junit Version:3.8.1

------------------------------------------------------------------------------------------------

Eclipse和Junit 大家应该都很熟悉了。这里我也不打算去讲为什么需要做这样的组合。为什么需要测试。为什么测试还有那么多讲究和学问。用一个最简单的例子，让还没有使用过的朋友，有一个简单的认识。主要是发图玩玩

1）看看完成后的效果图


2）       运行Eclipse。新建一个workplace项目，点击 file->new->project，选择Java项目，点击下一步。写一个项目名称，例如UseJUnit。点击Finish。这样就完成新项目的建立。再来配置一下Eclipse，在构建路径中添加JUnit类库。在工具条上点击项目->属性，选择Java Build Path，Libraries，选择 Add external JARs，浏览Junit被存储的目录，选择junit.jar，点击打开。你将会看见JUnit出现在库的列表中。点击确定，让Eclipse重建路径。

         

3）新建一个Class Person


4) 新建一个Test Class TestCaseWithJunit


代码如下：public void testSay() 方法是我自己加进去的



5) Run Test case
   

6) 看看测试结果
      

7）修改一下测试代码
   

8）再看测试结果






呵呵！ 第一次发图。如果上面的过程描述有什么不清楚的地方。请与我联系

2005-11-13  听涛 窗台

   MySQL           V4.1

-------------------------------------------------------------------------------------------------

       从名字看双胞胎一般的他们俩。是绝配吗？我也不知道，有时候，MySQL-Front会告诉我：“我不认识MySQL”。不要以为我和他有啥子关系。这就是我今天要谈到的问题。因为刚用MySQL一段时间。不知道还有没有更好的组合式用法。

1）用[MySQL Command Line Client]进入MySQL cmd操作模式

drop database dbName;

create database dbName;

use dbName;

2) 数据库建立好以后开始建立表

   drop table person;

      create table person (

         person_name varchar(16) not null primary key,

         person_pass varchar(32) not null,

         person_sex int(1) default '0' ,

         person_email varchar(30) default null,

         person_lastLogTime dateTime,

         active_status int(1) default '0'

);

3）  现在你可以插入一些数据

insert into person  values('goingmm','***','男', 'todogoingmm@163.com', '2005-11-5',1);

…………...........

4)  OK 现在可以查询出来看了

select * from person

突然感觉老在这里操作很是不方便。于是想起了MySQL-Front。打开看看，咦！没有找到数据库dbName。努力了1个小时。原因猜完，办法想尽。MySQL-Front还是说我认识他，你不要搞我拉！~果然，再搞 MySQL-Front死掉拉。有个性。

后来把刚才做的1）2）3）4）全部回滚。就是删掉数据库。在MySQL-Front里面先建立一个数据库。然后去cmd建立表，插入数据。最后回到MySQL-Front。哈哈，这回看到刚刚建立的数据库了。

不知道大家有没有遇到过这个问题。是MySQL-Front的bug吗？还有一些MySQL-Front很弱智的问题，比如SQL编辑器。希望他的下一个版本不要这么粗糙。毕竟MySQL 都5.0了


2005年11月5日

-----------------------------------------------------------------------------------------

■     被用户的应用程序调用的，用来完成基本的创建、读取、更新、删除操作以及查询操作的接口。这些接口是Hibernate实现用户程序的商业逻辑的主要接口，它们包括Session、Transaction和Query

■     Hibernate用来读取诸如映射表这类配置文件的接口，典型的代表有Configuration类

■     回调(Callback)接口。它允许应用程序能对一些事件的发生作出相应的操作，例如Interceptor、Lifecycle和Validatable都是这一类接口

■     一些可以用来扩展Hibernate的映射机制的接口，例如UserType、CompositeUserType和IdentifierGenerator。如果你确认有必要的话这些接口可由用户程序来实现。

Session接口

       Session接口对于Hibernate开发人员来说是一个最重要的接口。然而在Hibernate中，实例化的Session是一个轻量级的类，创建和销毁它都不会占用很多资源。这在实际项目中确实很重要，因为在客户程序中，可能会不断地创建以及销毁Session对象，如果Session的开销太大，会给系统带来不良影响。但值得注意的是Session对象是非线程安全的，因此在你的设计中，最好是一个线程只创建一个Session对象。

       Hibernate的设计者将session看作介于数据连接与事务管理一种中间接口。我们可以将session想象成一个持久对象的缓冲区，Hibernate能检测到这些持久对象的改变，并及时刷新数据库。我们有时也称Session是一个持久层管理器，因为它包含这一些持久层相关的操作，诸如存储持久对象至数据库，以及从数据库从获得它们。请注意，Hibernate 的session不同于JSP应用中的HttpSession。我们通常会将HttpSesion对象称为用户Session。

SessionFactory 接口

       他用到了一个设计模式[工厂模式]，用户程序从工厂类SessionFactory中取得Session的实例。

       但是请记住，SessionFactory并不是轻量级的！实际上它的设计者的意图是让它能在整个应用中共享。典型地来说，一个项目通常只需要一个SessionFactory就够了，但是当你的项目要操作多个数据库时，那你必须为每个数据库指定一个SessionFactory。

Configuration 接口

       Configuration接口的作用是对Hibernate进行配置，以及对它进行启动。在Hibernate的启动过程中，Configuration类的实例首先定位映射文档的位置，读取这些配置，然后创建一个SessionFactory对象。

Transaction 接口

       Transaction接口是一个可选的API，你可以选择不使用这个接口，取而代之的是Hibernate的设计者自己写的底层事务处理代码。 Transaction接口是对实际事务实现的一个抽象，这些实现包括JDBC的事务、JTA中的UserTransaction、甚至可以是CORBA事务。
为什么要这样设计呢？因为这样使开发者能够使用一个统一事务的操作界面，使得自己的项目可以在不同的环境和容器之间方便地移值。

Query和Criteria接口

       Query接口让你方便地对数据库及持久对象进行查询，它可以有两种表达方式：HQL语言或本地数据库的SQL语句。Query经常被用来绑定查询参数、限制查询记录数量，并最终执行查询操作

Callback 接口

       当一些有用的事件发生时。例如持久对象的载入、存储、删除时，Callback接口会通知Hibernate去接收一个通知消息。一般而言，Callback接口在用户程序中并不是必须的，但你要在你的项目中创建审计日志时，你可能会用到它。


2005年11月3日 夜  阴天 温度偏低

听涛[601]室 窗台

  【概念】
        1）Hibernate是一个面向java环境的对象/关系数据库映射(ORM)工具。
        2）ORM 表示一种技术，用来把对象模型表示的对象映射到基于SQL的关系模型中去。

  【目标】 
       对于开发者通常的数据持久化的编程任务。解放其中的95%，成为Java管理持续性数据问题的一种完整的解决方案
 
  【体现】
      他协调应用与关系数据库的交互，让开发者解放出来专注于手中的业务问题。他是一种非强迫性的解决方案

  【运行Hibernate需要的第三方库】
       dom4j (必需）:   Hibernate在解析XML配置和XML映射元文件时需要使用dom4j。
       CGLIB (必需）:  Hibernate在运行时使用这个代码生成库强化类（与Java反射机制联合使用）。 
       Commons Collections and Commons Logging (必需）: Hibernat使用Apache Jakarta Commons项目提供的多个工具类库
       ODMG4 (必需) : Hibernate提供了一个可选的ODMG兼容持久化管理界面。如果你需要映射集合，你就需要这个类库，
                                     就算你不是为了使用ODMG API （注意：为什么在Hibernate 3.0 就没有这个jar了？）
       Log4j (可选）：Log4j 是一款优秀的Debug工具，具体使用方式网络上有很多介绍

  先思考几个问题

 1）数据持久到底有那些成熟的方式？ 
    ■ 直接使用SQL和JDBC进行工作 也可以结合DAO模式
    ■ 序列化持续性机制 他提供了将对象图（应用状态）写到字节流中的能力，然后它可能被持续化到文件或数据库中。
         他也被Java的远程方法调用（RMI）使用来为复杂对象传递值语义。他的另一种用法是在机器集群中跨节点复制应
         用状态。
    ■ EJB实体Bean
    ■ JDO
    ■ ORM  对象-关系映射：中间的短线强调了当这两个领域相碰撞时出现的不匹配问题
    ■ XML持续层 XML持续层是序列化模式的变种。
    ■ 存储过程

 2）ORM解决方案有那些组成部分？
    ■ 在持续类的对象上执行基本的CRUD操作的一组API。
    ■ 用于指定查询的一种语言或一组API，这些查询会引用类和类属性。
    ■ 用于指定映射元数据的工具。
    ■ 实现ORM的一项技术，用来与事务对象交互以完成脏检查、懒关联存取和其它优化功能。

 3）实现ORM的有那些不同的方式？
    ■ 纯关系
    ■ 轻量对象映射
    ■ 中等对象映射
    ■ 完全对象映射

 4）相关的ORM有那些问题？
    ■ 持续类像什么？它们是细粒度的JavaBean吗？或者它们是一些类似于EJB的组件模型的实例吗？持续性工具有多么
         透明？我们需要为业务领域的类采用一种编程模型或一些规范吗？
    ■ 映射元数据是如何定义的？因为对象-关系转换完全由元数据控制，这些元数据的格式和定义是重要的核心问题。
         ORM工具应该提供一个图形化处理元数据的GUI吗？或者有定义元数据的更好的方法吗？
    ■ 我们应该映射类的继承层次吗？这有几种标准策略。多态关联、抽象类和接口怎么映射呢？
    ■ 对象同一性和相等性如何关联到数据库同一性（主键）？我们如何将特定类的实例映射到特定表的行。
    ■ 在运行时持续性逻辑如何与业务域对象交互？这是一个普通的编程问题，有许多的解决方案包括源代码生成、运行时
         反射、运行时字节码生成和编译时字节码增强。这个问题的解决方案可能影响到你的构建过程（但宁可如此，你也不
         愿受到其它像用户那样的影响）
    ■ 持续性对象的生命周期是什么样的？有些对象的生命周期依赖于其它关联对象的生命周期吗？
         我们如何将一个对象的生命周期转化为数据库行的生命周期？
    ■ 为排序、检索和合计提供了什么样的工具？应用可以在内存中处理其中的一些事情。但为了有效地使用关系技术有时
         需要通过数据库完成这些工作
    ■ 如何有效地取出关联数据？对关系数据的有效访问通常通过表连接实现。面向对象的应用通常通过导航对象图访问数
         据可能的话，两种数据访问模式应该避免n+1次选择的问题，以及它的补充笛卡尔积的问题（在一次查询中取出过多的
         数据)

  5）所有数据访问技术都不得不面对的问题有那些？
    ■ 事务和并发性
    ■ 缓存管理（和并发性）