最近在弄swing，需要由jcomponent生成bufferedimage，在csdn上发现一个好例子。下面是范例：


这样，jcomponent中的图像就保存到bufferedimage中了。
原文的链接：

        好久没有写blog了，距离上次写几乎已经是半年前的事情了。 这半年发生了不少事情。首先换了家公司，进了家金融企业，每天要西装革履的，一开始还真是不习惯。 这里开发是用的spring框架，以后要多研究研究spring的东西了。
        第二件事就是和恋爱了三年的女友结婚了，从此两人长相厮守，不知道时间久了会不会审美疲劳。呵呵。
        第三件事就是在深圳买了自己的小房子，虽然是小小的两房，不过我们已经很知足了。 而且刚好是赶在房价大涨前买的，还算走了点运气。换到现在，都不知道去哪里买好了。
        在这里要向一些留言和发邮件给我的网友道歉，前段时间实在是太忙，没有空回复你们的信息和邮件。请原谅！

      最近真是多事情忙，而且可能要忙到9月底。好久没有上来更新我的博客了，暂且发发牢骚。

      这一节是非常实用的一节，我在阅读此书的时候，一直在迷惑，究竟应该怎样管理session呢？因为session的管理是如此重要，类似于以前写程序对jdbc connection的管理。看完此节后，终于找到了方法。
      在各种session管理方案中，threadlocal模式得到了大量使用。threadlocal是java中一种较为特殊的线程绑定机制。通过threadlocal存取的数据，总是与当前线程相关，也就是说，jvm为每个运行的线程，绑定了私有的本定实例存取空间，从而为多线程环境经常出现的并发访问问题提供了一种隔离机制。
      下面是hibernate官方提供的一个threadlocal工具：


      针对web程序，还可以利用servlet2.3的filter机制，轻松实现线程生命周期内的session管理。下面是一个通过filter进行session管理的典型案例：

      数据分页显示，是很多b/s系统会遇到的问题。现在大多数主流数据库都提供了数据部分读取机制，而对于某些没有提供相应机制的数据而言，hibernate也通过其它途径实现了分页，如通过scrollable resultset，如果jdbc不支持scrollable resultset，hibernate也会自动通过resultset的next方法进行记录定位。hibernate的criteria、query等接口提供了一致的方法设定分页范围。下面是书中的例子：


      不过，我在测试的时候总是不能够正常工作，把setfetchsize方法换成setmaxresults方法才行。换成最新的mysql-connector-java-3.1.10-bin-g.jar驱动也是一样。

      hibernate通过lifecycle、validatable接口制定了实体对象crud过程中的回调方式。
      lifecycle接口中的onsave、onupdate、ondelete方法，如果返回true则意味着需要中止执行相应的操作过程。如果代码运行期间抛出了callbackexception，对应的操作也会被中止。注意，不要试图在这些方法中调用session进行持久化操作，这些方法中session无法正常使用。
      validatable.validate方法将在实体被持久化之前得到调用以对数据进行验证。此方法在实体对象的生命周期内可能被数次调用，因此，此方法仅用于数据本身的逻辑校验，而不要试图在此实现业务逻辑的验证。

---

      hibernate还引入了interceptor，为持久化事件的捕获和处理提供了一个非侵略性的实现。interceptor接口定义了hibernate中的通用拦截机制。session创建时即可指定加载相应的interceptor，之后，此session的持久化操作动作都将首先经由此拦截器捕获处理。简单的加载范例如下：
      需要注意的是，与lifecycle相同，interceptor的方法中不可通过session实例进行持久化操作。

      有兴趣的可以去参加看看，网址：

      最近真是忙，事情都挤到一块去了。 终于有时间又看了几页书。
      言归正传，hibernate中的collection类型分为有序集和无序集两类。这里所谓的有序和无序，是针对hibernate数据持久过程中，是否保持数据集合中的记录排列顺序加以区分的。无序集有set，bag，map几种，有序集有list一种。有序集的数据在持久化过程中，会将集合中元素排列的先后顺序同时固化到数据库中，读取时也会返回一个具备同样排列顺序的数据集合。
      hibernate中的collection类型是用的自己的实现，所以在程序中，不能够把接口强制转化成相应的jdk collection的实现。

---

      结果集的排序有两种方式：
      1. sort
         collection中的数据排序。
      2. order-by
         对数据库执行select sql时，由order by子句实现的数据排序方式。

      需要注意的是，order-by特性在实现中借助了jdk 1.4中的新增集合类linkedhashset以及linkedhashmap。因此，order-by特性只支持在1.4版本以上的jdk中运行。

      session.get/load的区别：
      1.如果未能发现符合条件的记录，get方法返回null，而load方法会抛出一个obejctnotfoundexception。
      2.load方法可返回实体的代理类类型，而get方法永远直接返回实体类。
      3.load方法可以充分利用内部缓存和二级缓存中现有数据，而get方法则仅仅在内部缓存中进行数据查找，如没有发现对应数据，将越过二级缓存，直接调用sql完成数据读取。

---

      session.find/iterate的区别：
      find方法将执行select sql从数据库中获得所有符合条件的记录并构造相应的实体对象，实体对象构建完毕之后，就将其纳入缓存。它对缓存只写不读，因此无法利用缓存。
      iterate方法首先执行一条select sql以获得所有符合查询条件的数据id，随即，iterate方法首先在本地缓存中根据id查找对应的实体对象是否存在，如果缓存中已经存在对应的数据，则直接以此数据对象作为查询结果，如果没有找到，再执行相应的select语句获得对应的库表记录（iterate方法如果执行了数据库读取操作并构建了完整的数据对象，也会将其查询结果纳入缓存）。

---

      query cache产生作用的情况：
      1.完全相同的select sql重复执行。
      2.在两次查询之间，此select sql对应的库表没有发生过改变。

---

      session.save方法的执行步骤：
      1.在session内部缓存中寻找待保存对象。内部缓存命中，则认为此数据已经保存（执行过insert操作），实体对象已经处于persistent状态，直接返回。
      2.如果实体类实现了lifecycle接口，则调用待保存对象的onsave方法。
      3.如果实体类实现了validatable接口，则调用其validate()方法。
      4.调用对应拦截器的interceptor.onsave方法（如果有的话）。
      5.构造insert sql，并加以执行。
      6.记录插入成功，user.id属性被设定为insert操作返回的新记录id值。
      7.将user对象放入内部缓存。
      8.最后，如果存在级联关系，对级联关系进行递归处理。

---

      session.update方法的执行步骤：
      1.根据待更新实体对象的key，在当前session的内部缓存中进行查找，如果发现，则认为当前实体对象已经处于persistent状态，返回。
      2.初始化实体对象的状态信息（作为之后脏数据检查的依据），并将其纳入内部缓存。注意这里session.update方法本身并没有发送update sql完成数据更新操作，update sql将在之后的session.flush方法中执行（transaction.commit在真正提交数据库事务之前会调用session.flush）。

---

      session.saveorupdate方法的执行步骤：
      1.首先在session内部缓存中进行查找，如果发现则直接返回。
      2.执行实体类对应的interceptor.isunsaved方法（如果有的话），判断对象是否为未保存状态。
      3.根据unsaved-value判断对象是否处于未保存状态。
      4.如果对象未保存（transient状态），则调用save方法保存对象。
      5.如果对象为已保存（detached状态），调用update方法将对象与session重新关联。

      事务的4个基本特性（acid）：
      1. atomic（原子性）：事务中包含的操作被看作一个逻辑单元，这个逻辑单元中的操作要么全部成功，要么全部失败。
      2. consistency（一致性）：只有合法的数据可以被写入数据库，否则事务应该将其回滚到最初状态。
      3. isolation（隔离性）：事务允许多个用户对同一个数据的并发访问，而不破坏数据的正确性和完整性。同时，并行事务的修改必须与其他并行事务的修改相互独立。
      4. durability（持久性）：事务结束后，事务处理的结果必须能够得到固化。

---

      数据库操作过程中可能出现的3种不确定情况：
      1. 脏读取（dirty reads）：一个事务读取了另一个并行事务未提交的数据。
      2. 不可重复读取（non-repeatable reads）：一个事务再次读取之前的数据时，得到的数据不一致，被另一个已提交的事务修改。
      3. 虚读（phantom reads）：一个事务重新执行一个查询，返回的记录中包含了因为其他最近提交的事务而产生的新记录。

      标准sql规范中，为了避免上面3种情况的出现，定义了4个事务隔离等级：
      1. read uncommitted：最低等级的事务隔离，仅仅保证了读取过程中不会读取到非法数据。上诉3种不确定情况均有可能发生。
      2. read committed：大多数主流数据库的默认事务等级，保证了一个事务不会读到另一个并行事务已修改但未提交的数据，避免了“脏读取”。该级别适用于大多数系统。
      3. repeatable read：保证了一个事务不会修改已经由另一个事务读取但未提交（回滚）的数据。避免了“脏读取”和“不可重复读取”的情况，但是带来了更多的性能损失。
      4. serializable：最高等级的事务隔离，上面3种不确定情况都将被规避。这个级别将模拟事务的串行执行。

---

      hibernate将事务管理委托给底层的jdbc或者jta，默认是基于jdbc transaction的。
      hibernate支持“悲观锁（pessimistic locking）”和“乐观锁（optimistic locking）”。
      悲观锁对数据被外界修改持保守态度，因此，在整个数据处理过程中，将数据处于锁定状态。悲观锁的实现，往往依靠数据库提供的锁机制。hibernate通过使用数据库的for update子句实现了悲观锁机制。hibernate的加锁模式有：
      1. lockmode.none：无锁机制
      2. lockmode.write：hibernate在insert和update记录的时候会自动获取
      3. lockmode.read：hibernate在读取记录的时候会自动获取
      4. lockmode.upgrade：利用数据库的for update子句加锁
      5. lockmode.upgrade_nowait：oracle的特定实现，利用oracle的for update nowait子句实现加锁
      乐观锁大多是基于数据版本（version）记录机制实现。hibernate在其数据访问引擎中内置了乐观锁实现，可以通过class描述符的optimistic-lock属性结合version描述符指定。optimistic-lock属性有如下可选取值：
      1. none：无乐观锁
      2. version：通过版本机制实现乐观锁
      3. dirty：通过检查发生变动过的属性实现乐观锁
      4. all：通过检查所有属性实现乐观锁