http://tech.it168.com/j/n/2007-03-05/200703051354348.shtml

PA作为一项对象持久化的标准，不但可以获得Java EE应用服务器的支持，还可以直接在Java SE中使用。

介绍得很清楚的文章

JPA概述

JPA(Java Persistence API)作为Java EE 5.0平台标准的ORM规范，将得到所有Java EE服务器的支持。Sun这次吸取了之前EJB规范惨痛失败的经历，在充分吸收现有ORM框架的基础上，得到了一个易于使用、伸缩性强的ORM规范。从目前的开发社区的反应上看，JPA受到了极大的支持和赞扬，JPA作为ORM领域标准化整合者的目标应该不难实现。 

JPA通过JDK 5.0注解或XML描述对象－关系表的映射关系，并将运行期的实体对象持久化到数据库中，图 1很好地描述了JPA的结构：

Sun引入新的JPA ORM规范出于两个原因：其一，简化现有Java EE和Java SE应用的对象持久化的开发工作；其二，Sun希望整合对ORM技术，实现天下归一。 

JPA由EJB 3.0软件专家组开发，作为JSR-220实现的一部分。但它不囿于EJB 3.0，你可以在Web应用、甚至桌面应用中使用。JPA的宗旨是为POJO提供持久化标准规范，由此可见，经过这几年的实践探索，能够脱离容器独立运行，方便开发和测试的理念已经深入人心了。目前Hibernate 3.2、TopLink 10.1.3以及OpenJpa都提供了JPA的实现。

JPA的总体思想和现有Hibernate、TopLink，JDO等ORM框架大体一致。总的来说，JPA包括以下3方面的技术： 

• ORM映射元数据，JPA支持XML和JDK 5.0注解两种元数据的形式，元数据描述对象和表之间的映射关系，框架据此将实体对象持久化到数据库表中； 
• JPA 的API，用来操作实体对象，执行CRUD操作，框架在后台替我们完成所有的事情，开发者从繁琐的JDBC和SQL代码中解脱出来。 
• 查询语言，这是持久化操作中很重要的一个方面，通过面向对象而非面向数据库的查询语言查询数据，避免程序的SQL语句紧密耦合。 

问题：EJB专家团队是如何摆脱事务描述符的?
　　回答：在会话bean和消息驱动bean中，可以通过描述符和注释来控制事务的行为。此外，我们将默认的事务属性更改为“REQUIRED”，这个默认值比以前的值“SUPPORTS”更常用。因此，完全不必为业务方法配置事务行为。
　　JPA实体仅供本地使用，重点关注域模型。因此，无法在JPA实体上配置事务性(或远程边界或安全性)。而是必须使用会话bean façade(或消息驱动bean)，才可以通过EJB协议使用这些实体。通常来说，这是一件好事，配置安全性、远程处理和事务的粒度应该比持久化数据的粒度粗很多。JPA着重关注持久化数据，以及与EJB的其他部分和Java EE规范集成起来照管其他企业关注点。
　　问题：推荐对主键使用“long”还是“Long”?如果允许使用null作为值，将会如何?
　　回答：这实际上取决于您的数据模型。如果您的数据模型允许主键为null，那么使用Long，如果您的数据模型规定主键列不能为null，则使用 long更合适。总的来说，我认为对于非复合主键，允许null作为合法值容易产生混淆，因此我倾向于使用long，而不是Long。
　　问题：您说EJB 2.0不支持继承，但是可以在几个不同位置(远程/bean)使用继承，只是不在本地使用而已。请解释一下。
　　回答：根据EJB 2.1规范的附录D3：
　　当前的EJB规范未指定组件继承的概念。
　　另一方面，JPA规范确实规定了实体继承的概念。我们已经处理了EJB 2.1规范中指出的各种问题和复杂性，现在允许完全的多态查询和关联。
　　问题：BEA计划什么时候支持/发布EJB3?
　　WebLogic Server 10 Technology Preview 是完全符合规范的Java EE 5应用服务器。它包括完整的EJB3支持。WebLogic Server 10大概于三月下旬发布。
　　此外，Kodo 是完全符合规范的生产就绪JPA实现，并且已经发布。
　　问题：JPA是否支持组合主键?
　　回答：JPA支持自然ID和组合ID，以及数据库指派或实现指派的数字值。
　　问题：是否存在Spring模板，像JDBC模板一样可以在容器外部使用?
　　回答：是的，Spring 2有JPA模板。但是，Spring 2可以对任何标记着@Repository的bean执行JPA异常转译。因此，总的来说，对于新的应用程序，最好直接使用JPA API，而不是另一个模板层。对于使用模板和正在迁移到JPA的现有应用程序来说，使用模板方法比较合理。
　　此外，可以像在Java EE服务器中一样将JPA的持久化单元部署到Spring，Spring对JPA规范中指出的EntityManager注入和查找服从容器规则。
　　问题：JPA是否支持JDK1.4?
　　回答：JPA需要Java 5或更新版本。
问题：使用范围查询时，它是否也会返回结果总数(例如，返回538项结果中的1-10项)?
　　回答：不，要想获得总数，必须发出另外一个查询。通用模式是，在第一次执行搜索时获得总数，然后通过页面浏览结果，将总数存储到方便的位置(会话状态、cookie等)：

　　if (isFirstPage()) { // this is the first time we're executing this query 
　　Query q = em.createQuery("SELECT COUNT(p) FROM Product p WHERE ..."); 
　　long count = ((Long) q.getSingleResult()).longValue(); 
　　// store count somewhere stateful 
　　} 
　　Query q = em.createQuery("SELECT p FROM Product p WHERE ..."); 
　　q.setFirstResult(page * PAGE_SIZE); // page is stored somewhere stateful 
　　q.setMaxResults(PAGE_SIZE); 

很清楚，还有源码下载

另外，在DAO和service层的代码中，除非是为了异常的转化、重新抛出，否则不要捕捉和处理异常，否则AOP在拦截的时候就不能捕捉到异常，也就不能正确执行回滚。这一点通常很容易被忽视，只有在明白了spring的事务处理机制后，才能领会到。

对于hibernate的异常，spring会包装hibernate的upckecked hibernateException到DAOAccessException，并且抛出，在事务管理层，一旦接收到DAOAccessException就会触发事务的回滚，同时该异常会继续向上层抛出，供上层进一步处理，比如在UI层向用户反馈错误信息等。

这里，当Boot对象调用FooService来进行事务操作时，由于在事务操作时抛出了unchecked exception，被Spring的AOP事务处理模块拦截，触发了事务的回滚，同时最终在控制台上打出了“事务操作出现异常”，说明spring在触发了数据库回滚的同时又重新抛出了该异常。

模式

package x.y.service;

public class Foo {
}

package x.y.service;

import org.springframework.dao.DataAccessException;

public interface FooService {
    
    Foo getFoo(String fooName);

    Foo getFoo(String fooName, String barName);

    void insertFoo(Foo foo)throws DataAccessException;

    void updateFoo(Foo foo)throws DataAccessException;
}

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
       http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">



    <!-- this is the service object that we want to make transactional -->
    <bean id="fooService" class="x.y.service.DefaultFooService" />

    <!-- the transactional advice (i.e. what 'happens'; see the <aop:advisor/> bean below) -->
    <tx:advice id="txAdvice" transaction-manager="txManager">
        <!-- the transactional semantics -->
        <tx:attributes>
            <!-- all methods starting with 'get' are read-only -->
            <tx:method name="get*" read-only="true" />

            <!-- other methods use the default transaction settings (see below) -->
            <tx:method name="*" />
        </tx:attributes>
    </tx:advice>

    <!-- ensure that the above transactional advice runs for any execution
        of an operation defined by the FooService interface -->
    <aop:config>
        <aop:pointcut id="fooServiceOperation"
            expression="execution(* x.y.service.FooService.*(..))" />
        <aop:advisor advice-ref="txAdvice"
            pointcut-ref="fooServiceOperation" />
    </aop:config>

    <!-- don't forget the DataSource -->
    <bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close">
        <property name="driverClassName" value="org.h2.Driver" />
        <property name="url"
            value="jdbc:h2:tcp://localhost/D:/try/data/sample;IFEXISTS=TRUE" />
        <property name="username" value="sa" />
        <property name="password" value="123456" />
    </bean>

    <!-- similarly, don't forget the PlatformTransactionManager -->
    <bean id="txManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
    </bean>
    <!-- other <bean/> definitions here -->
</beans>

结论

Spring推荐事务的控制在service层实现，而不是像单独使用hibernate那样，在dao层实现，这样的好处在于更好地支持declear方式的事务（service层通常提供接口，这样可以针对接口来定义事务策略，而不是针对具体的service实现，因此可以很方便地替换service的实现，而不需要修改事务的配置），更加灵活。同时，可以更加方面自然地实现全局事务的控制。

举例如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:aop="http://www.springframework.org/schema/aop"
    xmlns:tx="http://www.springframework.org/schema/tx"
    xsi:schemaLocation="
       http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd
       http://www.springframework.org/schema/tx http://www.springframework.org/schema/tx/spring-tx-2.0.xsd
       http://www.springframework.org/schema/aop http://www.springframework.org/schema/aop/spring-aop-2.0.xsd">



    <!-- this is the service object that we want to make transactional -->
    <bean id="fooService" class="x.y.service.DefaultFooService" />

    <!-- the transactional advice (i.e. what 'happens'; see the <aop:advisor/> bean below) -->
    <tx:advice id="txAdvice" transaction-manager="txManager">
        <!-- the transactional semantics -->
        <tx:attributes>
            <!-- all methods starting with 'get' are read-only -->
            <tx:method name="get*" read-only="true" />

            <!-- other methods use the default transaction settings (see below) -->
            <tx:method name="*" />
        </tx:attributes>
    </tx:advice>

    <!-- ensure that the above transactional advice runs for any execution
        of an operation defined by the FooService interface -->
    <aop:config>
        <aop:pointcut id="fooServiceOperation"
            expression="execution(* x.y.service.FooService.*(..))" />
        <aop:advisor advice-ref="txAdvice"
            pointcut-ref="fooServiceOperation" />
    </aop:config>

    <!-- don't forget the DataSource -->
    <bean id="dataSource"
        class="org.apache.commons.dbcp.BasicDataSource"
        destroy-method="close">
        <property name="driverClassName" value="org.h2.Driver" />
        <property name="url"
            value="jdbc:h2:tcp://localhost/D:/try/data/sample;IFEXISTS=TRUE" />
        <property name="username" value="sa" />
        <property name="password" value="123456" />
    </bean>

    <!-- similarly, don't forget the PlatformTransactionManager -->
    <bean id="txManager"
        class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
        <property name="dataSource" ref="dataSource" />
    </bean>
    <!-- other <bean/> definitions here -->
</beans>

使用service层方便了使用全局事务

对于横跨多个Hibernate SessionFacotry的分布式事务，只需简单地将 JtaTransactionManager 同多个 LocalSessionFactoryBean 的定义结合起来作为事务策略。你的每一个DAO通过bean属性得到各自的 SessionFactory 引用。在需要进行跨多个数据库的事务操作时，只需要定义一个service层，使用 JtaTransactionManager 作为事务策略，横跨多个DAO和多个session factories来划分事务，而不需要特殊的处理。

最近一个桌面的程序需要使用嵌入式数据库，选择了很多不同的嵌入式数据,最终选择了H2，性能是一个很重要的原因，下图是h2提供的Performance的比较图

http://www.h2database.com/html/images/performance.png

h2是Thomas Mueller提供的一个开源的、纯java实现的关系数据库，在google上面有讨论组h2-database@googlegroups.com，Thomas Mueller也非常热情，回答问题非常及时。

下面说下我最终选择h2的原因：

（1）性能、小巧

（2）同时支持网络版和嵌入式版本，另外还提供了内存版

（3）有比较好的兼容性，支持相当标准的sql标准（实际上也不存在一个数据库能够100%符合标准）

（4）提供了非常友好的基于web的数据库管理界面

（5）支持hibernate

Transaction Isolation

This database supports the following transaction isolation levels:

• Serializable
  This is the default level.
  To enable, execute the SQL statement 'SET LOCK_MODE 0'
  or append ;LOCK_MODE=1 to the database URL: jdbc:h2:~/test;LOCK_MODE=1
• Read Committed
  Read locks are released immediately. Higher concurrency is possible when using this level.
  This is the isolation level used for many database systems.
  To enable, execute the SQL statement 'SET LOCK_MODE 0'
  or append ;LOCK_MODE=3 to the database URL: jdbc:h2:~/test;LOCK_MODE=3
• Read Uncommitted
  This level means that transaction isolation is disabled.
  To enable, execute the SQL statement 'SET LOCK_MODE 0'
  or append ;LOCK_MODE=0 to the database URL: jdbc:h2:~/test;LOCK_MODE=0

When using the isolation level 'serializable', dirty reads, non-repeatable reads, and phantom reads are prohibited.

• Dirty Reads
  Means a connection can read uncommitted changes made by another connection.
  Possible with: read uncommitted
• Non-Repeatable Reads
  A connection reads a row, another connection changes a row and commits, and the first connection re-reads the same row and gets the new result.
  Possible with: read uncommitted, read committed
• Phantom Reads
  A connection reads a set of rows using a condition, another connection inserts a row that falls in this condition and commits, then the first connection re-reads using the same condition and gets the new row.
  Possible with: read uncommitted, read committed

Table Level Locking

select calldate,

sum(case class when '1' then callcount else 0 end) as A类,

sum(case class when '2' then callcount else 0 end) as B类,

sum(case class when '3' then callcount else 0 end) as C类

from t group by calldate

最后结果：