这里所举的例子，都是基于这样的一个情景，Item中包含有Images。

<set name="images" lazy="true" table="ITEM_IMAGE">

<key column="ITEM_ID"/>

<element type="string" column="FILENAME" not-null="true"/>

</set>

这里的<key>定义了外键ITEM_ID，<elememt>则声明了集合的内部数据元素。<set>定义的集合中不可以有重复的数据。

<idbag name="images" lazy="true" table="ITEM_IMAGE">

<collection-id type="long" column="ITEM_IMAGE_ID">

<generator class="sequence"/>

</collection-id>

<key column="ITEM_ID"/>

<element type="string" column="FILENAME" not-null="true"/>

</idbag>

ITEM_IMAGE_ID为主键，而ITEM_ID则为外键，<element>元素不变，这就允许集合中的数据重复。

<list name="images" lazy="true" table="ITEM_IMAGE">

<key column="ITEM_ID"/>

<index column="POSITION"/>

<element type="string" column="FILENAME" not-null="true"/>

</list>

这里为ITEM_IMAGE表添加了index，整个表的主键是ITEM_ID和POSITION构成的复合主键，它允许集合中的数据根据POSITION进行排序。

<map name="images"

lazy="true"

table="ITEM_IMAGE"

sort="natural">

<key column="ITEM_ID"/>

<index column="IMAGE_NAME" type="string"/>

<element type="string" column="FILENAME" not-null="true"/>

</map>

这里为ITEM_IMAGE表添加了index，整个表的主键是ITEM_ID和POSITION构成的复合主键，它允许集合中的数据根据sort指定的内容进行排序，这里允许用户对sort进行定制。

<map name="images"

lazy="true"

table="ITEM_IMAGE"

order-by="IMAGE_NAME asc">

<key column="ITEM_ID"/>

<index column="IMAGE_NAME" type="string"/>

<element type="string" column="FILENAME" not-null="true"/>

</map>

这里采用的是orbder-by，注意sort和order-by的区别。Sort是在内存中使用comparator进行排序，而order-by则是在数据库中使用SQL语句进行排序。

<set name="images"

lazy="true"

table="ITEM_IMAGE"

order-by="IMAGE_NAME asc">

<key column="ITEM_ID"/>

<composite-element class="Image">

<property name="name" column="IMAGE_NAME" not-null="true"/>

<property name="filename" column="FILENAME" not-null="true"/>

<property name="sizeX" column="SIZEX" not-null="true"/>

<property name="sizeY" column="SIZEY" not-null="true"/>

</composite-element>

</set>

这里定义了一个新的Image类，它不是实体类(entity class)，而是一个简单的值类型(value type)，仅仅是父实体的一个component，其生命周期完全由包含其的父实体 (parent entity) ITEM控制。这里Image类中包含有数据ITEM_ID、 IMAGE_NAME、FILENAME、SIZEX、和SIZEY。

<set name="images"

lazy="true"

table="ITEM_IMAGE"

order-by="IMAGE_NAME asc">

<key column="ITEM_ID"/>

<composite-element class="Image">

<parent name="item"/>

<property name="name" column="IMAGE_NAME" not-null="true"/>

<property name="filename" column="FILENAME" not-null="true"/>

<property name="sizeX" column="SIZEX" not-null="true"/>

<property name="sizeY" column="SIZEY" not-null="true"/>

</composite-element>

</set>

前面定义的IMAGE类中，并不包含有对父实体ITEM的引用。也就是说，只可以从ITEM中导航到IMAGE中，但是在IMAGE无法得到ITEM。这可以通过<parent>实现。这样IMAGE类中就含有一个数据成员item，指向其父实体。

但是，它是无法做到真正的双向导航的。例如：通过SQL查询直接得到IMAGE后，但是如同普通的值类型一样，IMAGE对象的item是null，你无法从component如此直接得到其父对象，这必须由通过父－子关系的entity完成。

In our CaveatEmptor application, both the user who posted a comment and any system administrator can open an Edit Comment screen to delete or edit the text of a comment. Suppose two different administrators open the edit screen to view the same comment simultaneously. Both edit the comment text and submit their changes. At this point, we have three ways to handle the concurrent attempts to

write to the database:

■ Last commit wins—Both updates succeed, and the second update overwrites the changes of the first. No error message is shown.

■ First commit wins—The first modification is persisted, and the user submitting the second change receives an error message. The user must restart the business process by retrieving the updated comment. This option is often called optimistic locking.

■        Merge conflicting updates—The first modification is persisted, and the second modification may be applied selectively by the user.

在我们的CavertEmptor中，用户和系统管理员都可以打开“编辑cooment”功能，删除或者编辑评论。假设同时有两个管理员对同一个评论打开编辑功能，他们都对评论进行编辑然后提交。这是，我们发现可能有三种方式对此并发操作进行处理、写入数据库：

   后者提交获胜－两次更新都成功，但是第二次更新将会覆盖第一次的更新，不显示任何错误。

   前者提交获胜－第一个提交者成功，更新数据库，后一个提交失败，并返回错误信息。用户必须重新开始整个业务过程，取得被更新的评论。者就是常说的“乐观锁”。

   合并更新冲突－第一个更新被保存，而第二个更新则由用户选择是否保存。

The first option, last commit wins, is problematic; the second user overwrites the changes of the first user without seeing the changes made by the first user or even knowing that they existed. In our example, this probably wouldn’t matter, but it would be unacceptable for some other kinds of data. The second and third options are usually acceptable for most kinds of data. From our point of view, the third option is just a variation of the second—instead of showing an error message, we show the message and then allow the user to manually merge changes. There is no single best solution. You must investigate your own business requirements to decide among these three options.

上面的第一个方案是有问题的：第二个用户在不知道改变、甚至不知道第一个用户已经操作的情况下，直接重写了数据库。在我们的例子中，也许是没关系的，但是对于某些应用是不可接受的。第二个和第三个方案对于绝大部分数据是可以结束的。按照我们的观点，第三个是第二个的变种，它不是显式错误信息，而是给用户进行选择，允许用户手工合并对数据的修改。这里并没有一个最完美的解决方案。你必须根据你自己项目的需要自行选择方案。

The first option happens by default if you don’t do anything special in your application。On the other hand, Hibernate can help you implement the second and third strategies, using managed versioning for optimistic locking.

如果在你的项目中不采取任何措施，那么会默认使用第一个方案。但是，hibernate可以通过使用对“乐观锁”使用“管理版本”，帮助你实现第二个或第三个方案。

Managed versioning relies on either a version number that is incremented or a timestamp that is updated to the current time, every time an object is modified. For Hibernate managed versioning, we must add a new property to our Comment class and map it as a version number using the <version> tag. First, let’s look at the changes to the Comment class:

public class Comment {

...

private int version;

...

void setVersion(int version) {

this.version = version;

}

int getVersion() {

return version;

}

}

“管理版本”使用版本号或者时间戳对数据进行标记，每次数据在更新的时候，它都会被更新。对于hibernate，我们必须给Comment类，添加新的属性，然后使用<version>标签对其进行映射。首先让我们来看一下Comment类的改变：

public class Comment {

...

private int version;

...

void setVersion(int version) {

this.version = version;

}

int getVersion() {

return version;

}

}

You can also use a public scope for the setter and getter methods. The <version> property mapping must come immediately after the identifier property mapping in the mapping file for the Comment class:

<class name="Comment" table="COMMENTS">

<id ...

<version name="version" column="VERSION"/>

...

</>

你可以使用public的setter或getter方法，这里的<version>映射的定义必须紧跟在映射文件中comment类的id后面。

<class name="Comment" table="COMMENTS">

<id ...

<version name="version" column="VERSION"/>

...

</>

You don’t need to set the value of the version or timestamp property yourself; Hibernate will initialize the value when you first save a Comment, and increment or reset it whenever the object is modified. Whenever Hibernate updates a comment, it uses the version column in the SQLWHERE clause:

update COMMENTS set COMMENT_TEXT='New comment text', VERSION=3

where COMMENT_ID=123 and VERSION=2

你无需自己手工去修改这里的版本号或者时间戳，hibernate将会在你保存Commment的时候对其初始化，然后在对象每次被更新的时候即使更新其版本号和时间戳。无论hibernate何时更新comment,它都会在SQL语句的where后面加上version列：

update COMMENTS set COMMENT_TEXT='New comment text', VERSION=3

where COMMENT_ID=123 and VERSION=2

If another application transaction would have updated the same item since it was read by the current application transaction, the VERSION column would not contain the value 2, and the row would not be updated. Hibernate would check the row count returned by the JDBC driver—which in this case would be the number of rows updated, zero—and throw a StaleObjectStateException. Using this exception, we might show the user of the second application transaction an error message (“You have been working with stale data because another user modified it!”) and let the first commit win. Alternatively, we could catch the exception and show the second user a new screen, allowing the user to manually merge changes between the two versions.

如果某个事务已经更新了某个数据，而另外一个事务也准备更新此数据，但是当时它取得数据的版本号是2，而此时由于该数据已经被更新过，新版本号是3，因此将无法更新数据库中的任何的数据。这时候hibernate将会检查jdbc的返回行数－如果未有任何数据行被更新，则返回0－因此将会抛出StaleObjectStateException异常。

Using this exception, we might show the user of the second application transaction an error message (“You have been working with stale data because another user modified it!”) and let the first commit win. Alternatively, we could catch the exception and show the second user a new screen, allowing the user to manually merge changes between the two versions.

Session（会话）接口是Hibernate应用使用的主要接口。会话接口的实例是轻量级的并且创建与销毁的代价也不昂贵。这很重要因为你的应用可能始终在创建与销毁会话，可能每一次请求都会如此。Hibernate会话并不是线程安全的因此应该被设计为每次只能在一个线程中使用。

Hibernate会话是一个介于连接和事务之间的概念。你可以简单地认为会话是对于一个单独的工作单元已装载对象的缓存或集合。Hibernate可以检测到这个工作单元中对象的改变。我们有时也将会话称为持续性管理器，因为它也是与持续性有关的操作例如存储和取出对象的接口。注意，Hibernate会话与Web层的HttpSession没有任何关系。当我们在本书中使用会话时，我们指的是Hibernate会话。为了区别，有时我们将HttpSession对象称为用户会话。

SessionFactory接口

应用从SessionFactory（会话工厂）里获得会话实例。与会话接口相比，这个对象不够令人兴奋。

会话工厂当然不是轻量级的！它打算在多个应用线程间进行共享。典型地，整个应用只有唯一的一个会话工厂——例如在应用初始化时被创建。然而，如果你的应用使用Hibernate访问多个数据库，你需要对每一个数据库使用一个会话工厂。

package com.oreilly.hh;

import net.sf.hibernate.*;
import net.sf.hibernate.cfg.Configuration;

import java.sql.Time;
import java.util.Date;

/**//**
 * Create sample data, letting Hibernate persist it for us.
 */
public class CreateTest {

    public static void main(String args[]) throws Exception {
        // Create a configuration based on the properties file we've put
        // in the standard place.
        Configuration config = new Configuration();

        // Tell it about the classes we want mapped, taking advantage of
        // the way we've named their mapping documents.
        config.addClass(Track.class);

        // Get the session factory we can use for persistence
        SessionFactory sessionFactory = config.buildSessionFactory();

        // Ask for a session using the JDBC information we've configured
        Session session = sessionFactory.openSession();
        Transaction tx = null;
        try {
            // Create some data and persist it
            tx = session.beginTransaction();

            Track track = new Track("Russian Trance",
                                    "vol2/album610/track02.mp3",
                                    Time.valueOf("00:03:30"), new Date(),
                                    (short)0);
            session.save(track);

            track = new Track("Video Killed the Radio Star",
                              "vol2/album611/track12.mp3",
                              Time.valueOf("00:03:49"), new Date(),
                              (short)0);
            session.save(track); 
            
             track = new Track("Gravity's Angel",
                              "vol2/album175/track03.mp3",
                               Time.valueOf("00:06:06"), new Date(),
                               (short)0);
            session.save(track);

            // We're done; make our changes permanent
            tx.commit();

        } catch (Exception e) {
            if (tx != null) {
                // Something went wrong; discard all partial changes
                tx.rollback();
            }
            throw e;
        } finally {
            // No matter what, close the session
            session.close();
        }

        // Clean up after ourselves
        sessionFactory.close();
    }
}

When it comes time to actually perform persistence, we ask the SessionFactory to open a Session for us (line 27), which establishes a JDBC connection to the database, and provides us with a context in which we can create, obtain, manipulate, and delete persistent objects. As long as the session is open, a connection to the database is maintained, and changes to the persistent objects associated with the session are tracked so they can be applied to the database when the session is closed. Conceptually you can think of a session as a 'large scale transaction' between the persistent objects and the database, which may encompass several database-level transactions. Like a database transaction, though, you should not think about keeping your Hibernate session open over long periods of application existence (such as while you're waiting for user input). A single session is used for a specific and bounded operation in the application, something like populating the user interface or making a change that has been committed by the user. The next operation will use a new session. Also note that Session objects are not thread safe, so they cannot be shared between threads. Each thread needs to obtain its own session from the factory.

现在开始讲述“持久化操作”。在第27行，使用SessionFactory打开了Session，建立了数据库JDBC的连接，（该连接已经进行了初始化），我们可以借用它进行一系列的操作，例如：创建、获取、操纵、删除持久化对象。只要session处于open状态，那么对数据库的连接就一直建立着，所有对已经和session绑定的持久化对象的操作都会被记录下来，并且在session关闭的时候，所有的这些操作就会被更新到数据库中。从概念上理解，你可以将session看作一个在持久化对象和数据库之间的“大规模的事务”，它可以跨越几个数据库事务。正如数据库事务那样，你不该在程序中将hibernate session长时间的打开着（例如当程序在等待用户输入的时候），程序中的每个单独的操作都该采用单独的session，例如在“弹出用户界面，或者将用户的修改提交到数据库”中，就该使用两个session。同样需要注意的是，session是线程不安全的，因此无法在线程之间共享session，每个线程都应该使用SessionFactory建立自己的sess。

We need to look more closely at the lifecycle of mapped objects in Hibernate, and how this relates to sessions, because the terminology is rather specific and the concepts are quite important. A mapped object such as an instance of our Track class moves back and forth between two states with respect to Hibernate: transient and persistent. An object that is transient is not associated with any session. When you first create a Track instance using new(), it is transient; unless you tell Hibernate to persist it, the object will vanish when it is garbage collected or your application terminates.

下面我们对hibernate中被映射对象的声明周期进行说明，因为被映射对象相关的术语是相当特别的、它的概念也是很重要的。在hibernate中，被映射对象（例如程序中的Track对象）会在两个状态中不断的来回切换：临时（transient）状态和持久（persistent）状态。未曾与session绑定的对象就处于临时状态，例如程序中刚开始new出来的Track对象，它就处于临时状态。除非你通知hibernate对它进行持久化，否则整个对象就会在垃圾收集器回收或者程序结束的时候消逝。

Passing a transient mapped object to a Session's save() method causes it to become persistent. It will survive garbage collection and termination of the Java VM, staying available until it is explicitly deleted. (There is a related distinction between entities and values discussed at the beginning of Appendix A. Mapped objects that have been persisted are called entities, even if they do not currently exist as an instance in any virtual machine.) If you've got a persistent object and you call Session's delete() method on it, the object transitions back to a transient state. The object still exists as an instance in your application, but it is no longer going to stay around unless you change your mind and save it again; it's ceased being an entity.

但是，将一个临时对象使用session的save方法保存之后，它就处于持久状态，即使在垃圾回事或者Java VM结束之后，它都一直存在，知道该对象被明确删除为止（在附录A开头有相关“entities和values区别”的讨论，即使其在虚拟机中并不真实存在着一个对象与之相对应）。当你对持久化对象调用session.delete()方法时，该对象又变为临时状态。虽然该对象仍然在程序中做为一个实例存在着，但是除非你改变主意再次将其持久化，那么它将很快的消逝，它的“实体(entity)”也就愕然而之。

On the other hand, and this point is worth extra emphasis, if you haven't deleted an object (so it's still persistent), when you change its properties there is no need to save it again for those changes to be reflected in the database. Hibernate automatically tracks changes to any persistent objects and flushes those changes to the database at appropriate times. When you close the session, any pending changes are flushed.

另一方面，需要强调的是：如若你不删除某持久化对象，那么当你改变其属性时，并不需要显示的对其的改变进行保存。hibernate将会自动的跟踪到你对持久化对象的改变，然后在适当的时候将这些改变填入到数据库中。

An important but subtle point concerns the status of persistent objects you worked with in a session that has been closed, such as after you run a query to find all entities matching some criteria (you'll see how to do this in the upcoming section, 'Finding Persistent Objects'). As noted above, you don't want to keep this session around longer than necessary to perform the database operation, so you close it once your queries are finished. What's the deal with the mapped objects you've loaded at this point? Well, they were persistent while the session was around, but once they are no longer associated with an active session (in this case because the session has been closed) they are not persistent any longer. Now, this doesn't mean that they no longer exist in the database; indeed, if you run the query again (assuming nobody has changed the data in the meantime), you'll get back the same set of objects; they're still entities. It simply means that there is not currently an active correspondence being maintained between the state of the objects in your virtual machine and the database. It is perfectly reasonable to carry on working with the objects. If you later need to make changes to the objects and you want the changes to 'stick,' you will open a new session and use it to save the changed objects. Because each entity has a unique ID, Hibernate has no problem figuring out how to link the transient objects back to the appropriate persistent state in the new session.

下面讨论“在session关闭后，和session绑定的持久化对象的状态”的问题。例如当你执行了一个查询，得到了你所需要的实体对象之后，正如前面所述的那样，你不应该将session保持过久，使之超出数据库操作的范围，这时候你将会关闭session。那么此时那些已经载入的映射对象处于什么状态呢？答案是这样的，在session的打开的过程中，它是处于持久化状态，但是它一旦不在和active session（因为此时session已经关闭）绑定，那么它就处于持久化状态。但是，这并不意味着他们在数据库中就不再存在，事实上，如果你再次执行查询（假设此间无人修改数据），那么你将可以得到同样的集合数据。也就是说，虚拟机中的对象所处的状态和数据库中的实体数据的状态之间并没有必然的联系。这时候，你可以对那些对象进行自己的操作，如果你改变了一些对象的数据，并想将其存储到数据库中，那么你必须重新建立一个session，使用它保存那些经过改变的数据。因为每个实体都有自己的唯一ID，因此hibernate可以很容易的在新的session中计算出如何将临时对象重新转换为相应的持久对象。

Armed with these concepts and terms, the remainder of the example is easy enough to understand. Line 31 sets up a database transaction using our open session. Within that, we create a few Track instances containing sample data and save them in the session (lines 33-50), turning them from transient instances into persistent entities. Finally, line 53 commits our transaction, atomically (as a single, indivisible unit) making all the database changes permanent. The try/catch/finally block wrapped around all this shows an important and useful idiom for working with transactions. If anything goes wrong, lines 56-60 will roll back the transaction and then bubble out the exception, leaving the database the way we found it. The session is closed in the finally portion at line 63, ensuring that this takes place whether we exit through the 'happy path' of a successful commit, or via an exception that caused rollback. Either way, it gets closed as it should.

通过上面的概念的讲述和讨论，那么例子中的其他部分也就很好理解了。第31行，使用打开的session建立了数据库事务。在事务中，33－50行创建了一个Track对象，并在session中将其保存，将其从临时对象变为持久对象。最后，53行提交事务，原子性的执行数据库改变。这里的try/catch/finally封装了事务处理中常出现的idom。一旦出现任何问题，56－60行就会回滚事务，然后抛出异常，保证数据库维持原状。无论如何，都会执行finnally块中的63行，无论在成功执行或者出现错误回滚的情况下，都会关闭session。

At the end of our method we also close the session factory itself on line 67. This is something you'd do in the 'graceful shutdown' section of your application. In a web application environment, it would be in the appropriate lifecycle event handler. ^[3.1] In this simple example, when the main() method returns, the application is ending.

在方法的最后67行，将会关闭session factory。这是你的应用程序正常退出时应该执行的操作。在Web程序中，你则需要使用一定的生命周期事件处理器，完成此操作。在我们的例子中，在main退出的时候，也就是程序中止的时间。
 

<?xml version="1.0"?>
<project name="Harnessing Hibernate: The Developer's Notebook"
         default="db" basedir=".">

  <!-- Set up properties containing important project directories -->
  <property name="source.root" value="src"/>
  <property name="class.root" value="classes"/>
  <property name="lib.dir" value="lib"/>
  <property name="data.dir" value="data"/>

  <!-- Set up the class path for compilation and execution -->
  <path id="project.class.path">
      <!-- Include our own classes, of course -->
      <pathelement location="${class.root}" />
      <!-- Include jars in the project library directory -->
      <fileset dir="${lib.dir}">
        <include name="*.jar"/>
      </fileset>
  </path>

  <target name="db" description="Runs HSQLDB database management UI
against the database file--use when application is not running">
      <java classname="org.hsqldb.util.DatabaseManager"
            fork="yes">
         <classpath refid="project.class.path"/>
         <arg value="-driver"/>
         <arg value="org.hsqldb.jdbcDriver"/>
         <arg value="-url"/>
         <arg value="jdbc:hsqldb:${data.dir}/music"/>
         <arg value="-user"/>
         <arg value="sa"/>
      </java>
  </target>

  <!-- Teach Ant how to use Hibernate's code generation tool -->
  <taskdef name="hbm2java"
           classname="net.sf.hibernate.tool.hbm2java.Hbm2JavaTask"
           classpathref="project.class.path"/>

  <!-- Generate the java code for all mapping files in our source tree -->
  <target name="codegen"
          description="Generate Java source from the O/R mapping files">
    <hbm2java output="${source.root}">
      <fileset dir="${source.root}">
        <include name="**/*.hbm.xml"/>
      </fileset>
    </hbm2java>
  </target>

  <!-- Create our runtime subdirectories and copy resources into them -->
  <target name="prepare" description="Sets up build structures">
    <mkdir dir="${class.root}"/>

    <!-- Copy our property files and O/R mappings for use at runtime -->
    <copy todir="${class.root}" >
      <fileset dir="${source.root}" >
        <include name="**/*.properties"/>
        <include name="**/*.hbm.xml"/>
      </fileset>
    </copy>
  </target>

  <!-- Compile the java source of the project -->
  <target name="compile" depends="prepare"
          description="Compiles all Java classes">
    <javac srcdir="${source.root}"
           destdir="${class.root}"
           debug="on"
           optimize="off"
           deprecation="on">
      <classpath refid="project.class.path"/>
    </javac>
  </target>

  <!-- Generate the schemas for all mapping files in our class tree -->
  <target name="schema" depends="compile"
          description="Generate DB schema from the O/R mapping files">

    <!-- Teach Ant how to use Hibernate's schema generation tool -->
    <taskdef name="schemaexport"
             classname="net.sf.hibernate.tool.hbm2ddl.SchemaExportTask"
             classpathref="project.class.path"/>

    <schemaexport properties="${class.root}/hibernate.properties"
                  quiet="no" text="no" drop="no">
      <fileset dir="${class.root}">
        <include name="**/*.hbm.xml"/>
      </fileset>
    </schemaexport>
  </target>

</project>

You may be wondering why the taskdef for the schema update tool is inside our schema target, rather than at the top of the build file, next to the one for hbm2java. Well, I wanted it up there too, but I ran into a snag that's worth explaining. I got strange error messages the first time I tried to build the schema target, complaining there was no hibernate.properties on the class path and our compiled Track class couldn't be found. When I ran it again, it worked. Some detective work using ant -verbose revealed that if the classes directory didn't exist when the taskdef was encountered, Ant helpfully removed it from the class path. Since a taskdef can't have its own dependencies, the solution is to move it into the schema target, giving it the benefit of that target's dependencies, ensuring the classes directory exists by the time the taskdef is processed.

也许你会奇怪，为何找了schema更新工具的taskdef会在schema的target中进行定义，而不是在build文件的顶部，紧接着hbm2java进行定义。刚开始我也是那样想的，这里我需要解释一下这里的问题。当第一次构建schema时，我得到了许多莫名奇妙的错误，报错信息是：在classpath中找不到hibernate.properties和Track类。但是再次构建的时候，就可以了。当使用命令“ant -verbose”时，你就可以发现其中的细节之所在。如果在ant解析到taskdef时，build文件中所使用的class目录并不存在，那么ant就会自己将此目录从classpath中移除。但是taskdef又无法定义自己的dependencies，因此这里不得不将其移入到schema target中，这样也就可以使用到target的dependencies，保证在ant处理taskdef的时候，class目录必然已经存在。

3）新建hibernate的mapping文件：File >> New >> Other >> Hibernate >> Mapping File. 
         这里需要选择mapping文件的存放位置
         填入你的数据库帐号，然后refresh，选择你的数据库表。这里的table pattern,schema pattern 自己知道哦。
         填写你的包名，然后确认。

4）生成各项java文件。
        右键单击mapping文件，然后选择hibernate synchronize-> synchronize files。 这就生成各项java文件了。
       如果你看不到，那就refresh整个工程的文件夹。

5）编写测试程序，使用那生成的java文件进行数据库操作。

    测试程序中所使用的两个接口是：{tablename}.java  ,  {tablename}DAO.java
   例如：如果你的表名是Person，那么你将用Person.java, PersonDAO.java
   这里的PersonDAO封装了hibernate的操作，更加方便了。

   自己观察一下吧，会有更多收获的。