package com.hibernate.higherApplication;
import java.util.Iterator;
import java.util.List;
import java.util.Set;
import junit.framework.TestCase;
import org.hibernate.Criteria;
import org.hibernate.Hibernate;
import org.hibernate.HibernateException;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.cfg.Configuration;
import org.hibernate.criterion.Expression;
public class DurationOperator extends TestCase {
private SessionFactory sessionFactory = null;
private Session session = null;
/**
* 初始化资源
*/
protected void setUp() throws Exception {
try {
//加载类路径下的hibernate.cfg.xml文件
Configuration config = new Configuration().configure();
//创建sessionFactory对象
sessionFactory = config.buildSessionFactory();
//创建session
session = sessionFactory.openSession();
} catch (HibernateException e) {
e.printStackTrace();
}
}
/**
* load/get方法均可以根据指定的实体类和id从数据库读取记录，并返回与之对应的实体对象。
* 区别在于：
* 1、如果未发现符合条件的记录，get方法返回null,而load方法抛出一个ObjectNotFoundException
* 2、load方法可以返回实体的代理类实例，而get方法永远直接返回实体类。
* 3、load方法可以充分利用内部缓存和二级缓存中的现有数据，而get方法则仅仅在内部缓存中进行数据查找，如果
* 没有发现数据，将越过二级缓存，直接调用SQL完成数据读取。
*
*/
public void loadOrGetData(){
TUser user = (TUser)session.load(TUser.class,new Integer(1));
}
/**
* 查询性能往往是一系统性能表现的一个重要方面。
* query.list方法通过一条select SQL实现了查询操作，而iterate方法，则执行了3次selectSQL，第一次获取了所有符合条件的记录
* 的id,之后，在根据各个id从库表中读取对应的哦记录，这是一个典型的N+1次查询问题。
*
* 我们进行query.list数据查询时，即使缓存中已经有一些符合条件的实体对象存在，我们也无法保证这些数据就是库表中所有符合条件的数据。假设
* 第一次查询条件是age>25,随即缓存中就包括了所有age>25的user数据;第二次查询条件为age>20,此时缓存中虽然包含了满足age>25d的
* 数据，但这些并不是满足条件age>20的全部数据
* 因此，query.list方法还是需要执行一次select sql以保证查询结果的完整性(iterate方法通过首先查询获取所有符合条件记录的id,以此保证
* 查询结果的完整性)。
* 因此，query.list方法实际上无法利用缓存，它对缓存只写不读。而iterate方法则可以充分发挥缓存带来的优势，如果目标数据只读或者读取相对
* 较为频繁，通过这种机制可以大大减少性能上的损耗。
*/
public void queryForList(){
String hql = "from TUser where age>?";
Query query = session.createQuery(hql);
query.setInteger(1,1);
List list = query.list();
for(int i=0;i<list.size();i++){
TUser user = (TUser)list.get(i);
System.out.println("User age:"+user.getAge());
}
}
public void queryForIterate(){
String hql = "from TUser where age>?";
Query query = session.createQuery(hql);
query.setInteger(1,1);
Iterator it = query.iterate();
while(it.hasNext()){
TUser user = (TUser)it.next();
System.out.println("User age:"+user.getAge());
}
}
/**
* 大数据量的批量读取(10W条)
* 解决方案：结合iterate方法和evict方法逐条对记录进行处理，将内存消耗保持在可以接受的范围之内。
* 在实际开发中，对于大批量数据处理，还是推荐采用SQL或存储过程实现，以获得较高的性能，并保证系统平滑运行。
*/
public void bigDataRead(){
String hql = "from TUser where age>?";
Query query = session.createQuery(hql);
query.setInteger("age", 1);
Iterator it = query.iterate();
while(it.hasNext()){
TUser user = (TUser)it.next();
//将对象从一级缓存中移除
session.evict(user);
//二级缓存可以设定最大数据缓存数量，达到峰值时会自动对缓存中的较老数据进行废除，但是我们这里还是通过
//编码指定将对象从二级缓存中移除，这有助保持缓存的数据有效性。
sessionFactory.evict(TUser.class,user.getId());
}
}
/**
* Query Cache弥补了find方法的不足，QueryCache中缓存的SQL及其结果及并非永远存在，当Hibernate发现此SQL对应的库表发生变动，
* 会自动将Query Cache中对应表的SQL缓存废除。因此Query Cache只在特定的情况下产生作用：
* 1、完全相同的select SQL重复执行。
* 2、在2次查询之间，此select SQL对应的库表没有发生过改变。
*/
public void queryForQueryCache(){
String hql = "from TUser where age>?";
Query query = session.createQuery(hql);
query.setInteger(1, 1);
//除了在这里设置QueryCache外，还要在hibernate.cfg.xml中进行设置
//<property name="hibernate.cache.use_query_cache">true</property>
query.setCacheable(true);
List userList = query.list();
}
/**
* 所谓延迟加载，就是在需要数据的时候，才真正执行数据加载操作。
* 延迟加载实现主要针对：
* 1、实体对象:通过class的lazy属性，我们可以打开实体对象的延迟加载功能。
* 2、集合
*/
public void queryForEntityLazy(){
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user = (TUser)userList.get(0);
//虽然使用了延迟加载，但是我们可以通过hibernate的初始化方法进行强制加载，这样即使session关闭之后，关联的对象仍让可以使用
Hibernate.initialize(user.getAddresses());
System.out.println("User name=>"+user.getAge());
Set hset =user.getAddresses();
TAddresses addr = (TAddresses)hset.toArray()[0];
System.out.println(addr.getAddress());
session.close();
}
/**
* 关闭资源
*/
protected void tearDown() throws Exception {
try{
session.close();
}catch(HibernateException e){
e.printStackTrace();
}
}
}
posted @
2010-01-02 15:27 王永庆 阅读(354) |
评论 (0) |
编辑 收藏
基于Java的缓存实现，最简单的方式莫过于对集合类数据类型进行封装。Hibernate提供了基于Hashtable的缓存实现机制，不过，由于其性能和功能上的局限，仅供开发调试中使用。同时，Hibernate还提供了面向第三方缓存实现的接口，如：
HashTable--------------------------------net.sf.hibernate.cache.HashtableCacheProvider
1、JSC
2、EHCache->默认的二级Cache实现。--------net.sf.encache.hibernate.Provider
3、OSCache-------------------------------net.sf.hibernate.cache.OSCacheProvider
4、JBoss Cache->分布式缓存---------------net.sf.hibernate.cache.TreeCacheProvider
5、SwarmCache----------------------------net.sf.hibernate.cache.SwarmCacheProvider
相对于JSC而言，EHCache更加稳定，并具备更好的混存调度性能，其缺陷是目前还无法做到分布式缓存。
首先设置hibernate.cfg.xml然后设置ehcache.xml最后设置缓存策略。
缓存同步策略决定了数据对象在缓存中的存取规则。为了使得缓存调度遵循正确的应用级事物隔离机制，我们必须为每个实体类指定相应的缓存同步策略。Hibernate提供4种内置的缓存同步策略：
1、read-only:只读。对于不会发生改变的数据，可使用只读型缓存。
2、nonstrict-read-write:如果程序对并发访问下的数据同步要求不是非常严格，且数据更新操作频率较低，可以采用本选项。
3、read-write:严格可读写缓存。
4、transactional:事务型缓存，必须运行在JTA事物环境中。
JDBC事物由Connection管理，也就是说，事务管理实际上是在JDBC Connection中实现。事务周期限于Connection的生命周期之类。同样，对于基于JDBC Transaction的Hibernate事务管理机制而言，事物管理在Session所以托的JDBCConnection中实现，事务周期限于Session的生命周期。
JTA事物管理则由JTA容器实现，JTA容器对当前加入事物的众多Connection进行调度，实现其事务性要求。JTA的事物周期可横跨多个JDBC Connectin生命周期。同样对于基于JTA事务的Hibernate而言，JTA事物横跨多个Session.
Hibernate支持2种锁机制：即通常所说的悲观锁和乐观锁。
悲观锁的实现，往往依靠数据库提供的锁机制。典型的悲观锁调用：
select * from account where name=="Erica" for update
package com.hibernate.higherApplication;
import java.util.List;
import junit.framework.TestCase;
import org.hibernate.Criteria;
import org.hibernate.HibernateException;
import org.hibernate.LockMode;
import org.hibernate.Query;
import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;
import org.hibernate.criterion.Expression;
public class LockOperator extends TestCase {
private Session session = null;
/**
* 初始化资源
*/
protected void setUp() throws Exception {
try {
//加载类路径下的hibernate.cfg.xml文件
Configuration config = new Configuration().configure();
//创建sessionFactory对象
SessionFactory sessionFactory = config.buildSessionFactory();
//创建session
session = sessionFactory.openSession();
} catch (HibernateException e) {
e.printStackTrace();
}
}
/**
* 悲观锁
* Hibernate的加锁模式有：
* 1、LockMode.NONE:无锁机制
* 2、LockMode.WRITE:Hibernate在Insert和Update记录的时候会自动获取
* 3、LockMode.READ:Hibernate在读取记录的时候会自动获取
* 上述3种锁机制为了保证update过程中对象不会被外界修改，在目标对象上加锁，与数据库无关
* 4、LockMode.UPGRADE:利用数据库的for update子句加锁
* 5、LockMode.UPGRADE_NOWAIT:oracle的特定实现
* 注意：只有在查询开始之前设定加锁，才会真正通过数据库的锁机制进行加锁处理。
*/
public void addPessimismLock(){
String hqlStr = "from TUser as user where user.name='Erica'";
Query query = session.createQuery(hqlStr);
query.setLockMode("user",LockMode.UPGRADE);//多所有返回的user对象加锁
List userList = query.list();//执行查询
}
/**
* 乐观锁
* 数据版本：即为数据增加一个版本标识，在基于数据库表的版本解决方案中，一般是通过为数据库表增加一个version字段来实现。
* 读取出数据时，将此版本号一同读出，之后更新时，对此版本号加1.此时，将提交数据的版本数据与数据库对应记录的当前版本信息
* 进行比对，如果提交的数据版本号大于数据库表当前版本号，则予以更新，否则认为是过期数据。
*
* Hibernate在其数据访问引擎中内置了乐观锁实现。如果不考虑外部系统对数据库的更新操作，利用Hibernate提供的透明化乐观锁
* 实现，将大大提升我们的生产力。见配置文件T_USER.hbm.xml
* 乐观锁机制避免了长事务中的数据加锁开销，大大提升了大并发量下的系统整体性能表象。
*
*/
public void addOptimismLock(){
Criteria criteria = session.createCriteria(TUser.class);
criteria.add(Expression.eq("name","Erica"));
List userList = criteria.list();
TUser user = (TUser)userList.get(0);
Transaction tx = session.beginTransaction();
user.setVersion(1);
tx.commit();
}
/**
* 关闭资源
*/
protected void tearDown() throws Exception {
try{
session.close();
}catch(HibernateException e){
e.printStackTrace();
}
}
}
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http：//hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<!--
none:无乐观锁
version:通过版本机制实现乐观锁
dirty:通过检查发生变动过的属性实现乐观锁
all通过检查所有属性实现乐观锁
-->
<class
name="org.hibernate.sample.TUSER"
table="t_user"
dynamic-update="true"
dynamic-insert="true"
optimistic-lock="version"
lazy="true"
>
<id
name="id"
column="id"
type="java.lang.Integer"
>
<generator class="native">
</generator>
</id>
<version name="version" column="version" type="java.lang.Integer">
</version>
<set name="addresses"
table="t_address"
lazy="true"
inverse="false"
cascade="all"
>
<key
column="user_id"
>
</key>
<one-to-many class=""/>
</set>
</class>
</hibernate-mapping>
posted @
2010-01-02 15:25 王永庆 阅读(552) |
评论 (0) |
编辑 收藏
实体对象，特指Hibernate O/R映射关系中的域对象。实体对象生命周期中的3种状态
1、Transient(自由状态)：所谓Transient,即实体对象在内存中的自由存在，它与数据库中的记录无关。
2、Persistent(持久状态)：即实体对象处于由Hibernate框架所管理的状态。
3、Detached(游离状态)：处于Persistent状态的对象，其对应的Session实例关闭之后，那么，此对象就处于"Detached"状态。
Transient状态的user对象与库表的数据缺乏对应关系，而Detached状态的user对象，却在库表中存在对应的记录，只不过由于Detached对象脱离了session这个数据操作平台，其状态的变化无法更新到库表中的对应记录。
处于Transient和Detached状态的对象统称为值对象(VO),而处于Persistent状态的对象称为持久对象(PO).这是站在实体对象是否被纳入Hibernate实体管理容器的立场加以区分的，非管理的实体对象统称为VO,而被管理的实体对象称为PO.
VO与PO的主要区别在于：
1、VO是相对独立的实体对象，处于非管理状态。
2、PO是由Hibernate纳入其实体管理容器的对象，它代表了与数据库中某条记录对应的Hibernate实体，PO的变化在事务提交时将反映到实际数据库中
3、如果一个PO与其对应的Session实例分离，那么此时，它又会变成一个VO。
不覆盖equals/hashCode方法的情况下我们要面对的问题：实体对象的跨session识别。解决办法一个是实现所谓的值比对，即在equals/hashCode方法中，对实体类的所有属性值进行比对.除了值比对，还有另外一种基于业务逻辑的对象判定方式业务关键信息判定。
tx.commint();方法中会调用session.flush()方法，在flush()方法中会执行2个主要任务
1、flushEverything();//刷新所有数据
2、execute(0);//执行数据库SQL完成持久化动作。
数据缓存：在特定硬件基础上缓存往往是提升系统性能的关键因素。缓存是数据库数据在内存中的临时容器，它包含了库表数据在内存中的临时拷贝，位于数据库与数据访问层之间。ORM在进行数据读取时，会根据其缓存管理策略，首先在缓存中查询，如果在缓存中发现所需数据，则直接以此数据作为查询结果加以利用，从而避免了数据库调用的性能开销。
相对内存操作而言，数据库调用是一个代价高昂的过程，对于典型企业及应用结构，数据库往往与应用服务器位于不同的物理服务器，这也就意味着每次数据库访问都是一次远程调用，Socket的创建与销毁，数据的打包拆包，数据库执行查询命令，网络传输上的延时，这些消耗都给系统整体性能造成了严重影响。
ORM的数据缓存应包含如下几个层次：
1、事务级缓存：事务级缓存是基于Session生命周期实现的，每个Session会在内部维持一个数据缓存，此缓存随着Session的创建而存在，因此也成为Session Level Cache(内部缓存)
2、应用级/进程级缓存：在某个应用中，或者应用中某个独立数据访问子集中的共享缓存。此缓存可由多个事物共享。在Hibernate中，应用级缓存在SessinFactory层实现，所有由此SessionFactory创建的Session实例共享此缓存。多实例并发运行的环境要特别小心进程级缓存的调用。
3、分布式缓存：分布式缓存由多个应用级缓存实例组成集群，通过某种远程机制实现各个缓存实例间的数据同步，任何一个实例的数据修改操作，将导致整个集群间的数据状态同步。由于多个实例间的数据同步机制，每个缓存实例发生的变动都会复制到其余所有节点中，这样的远程同步开销不可忽视。
Hibernate数据缓存分为2个层次，1、内部缓存2、二级缓存hibernate中，缓存将在以下情况中发挥作用：
1、通过ID加载数据时
这包括了根据id查询数据的Session.load方法，以及Session.ierate等批量查询方法
2、延迟加载
Session在进行数据查询操作时，会首先在自身内部的一级缓存中进行查找，如果一级缓存未能命中，则将在二级缓存中查询，如果二级缓存命中，则以此数据作为结果返回。
如果数据满足以下条件，则可将其纳入缓存管理
1、数据不会被第三方应用修改
2、数据大小在可接受的范围之内
3、数据更新频率较低
4、同一数据可能会被系统频繁引用
5、非关键数据(关键数据，如金融账户数据)
Hibernate本身并未提供二级缓存的产品化实现(只是提供了一个基于Hashtable的简单缓存以供调试)，而是为众多的第三方缓存组件提供了接入接口，我们可以根据实际情况选择不同的缓存实现版本。
posted @
2009-12-22 15:01 王永庆 阅读(209) |
评论 (0) |
编辑 收藏
比较字符串是否相等使用equals方法
使用"=="与equals到底有哪些不同?
equals:可以比较内容，是2个字符串内容的比较。
==：数值比较，比较的是内存地址的值是否相等。
一个字符串就是String类的匿名对象。
String name1 = new String("wyq");->开辟了2个空间，其中一个是垃圾空间。
String name2 = "wyq";->开辟了一个空间，所以应该选择它。
String的另一个特殊之处：String使用了Java中的共享模式，它只要发现在内存中有这块数据，不会在内存中重新生成。
String类中的内容一旦声明则不可改变。
StringBuffer与String的本质区别，在于StringBuffer可以改变。
this可以调用本类中的属性，也可以调用本类中的方法(含构造方法this())。
注意：构造方法本身必须在首行被使用，为了给类中的属性初始化。
this调用属性、本类方法、构造方法这三点是this的基本应用，也是最常用的，但是以上三点实际上可以综合成一点---表示当前对象。
this表示当前对象主要应用在一点：用于进行对象的比较。
public boolean compare(Person p1)
{
boolean flag = false;
Person p2 = this;
if(p1.name.equals(p2.name)&&p1.age==p2.age)
{
flag = true;
}
return flag;
}posted @
2009-12-08 09:56 王永庆 阅读(182) |
评论 (0) |
编辑 收藏 在软件中，要么全有要么全无的操作成为事务。事务允许你把几个操作组成一个单一的工作单元，这个工作单元要么全部发生要么全部不发生。如果每件事都顺利，那么这个事务是成功的。但是如果任何一件事情出错的话，那么已经发生的行为就被清除掉，就像什么事情都没发生一样。
Spring对事务管理有丰富的支持，程序控制的和声明式的。
原子性(Atomic):事务由一个或多个行为绑定在一起组成，好像是一个单独工作单元。原子性确保在十五中的所有操作要么都发生，要么都不发生。
一致性(Consistent):一旦一个事务结束了(不管成功失败)，系统所处的状态和它的业务规则是一致的。就是说数据应当不会被破坏。
隔离性(Isolated):事务应该允许多个用户操作同一数据，一个用户的操作不会和其他用户的操作相混淆。因此，事务必须是互相隔离的，防止并发读写同一数据的情况发生。
持久性(Durable):一旦事务完成，事务的结果应该持久化，这样不管什么样的系统崩溃，他们都将幸免于难。
Spring对程序控制事务管理的支持和EJB的有很大不同。EJB的事务管理和JTA密不可分，和EJB不同的是，Spring使用了一种回调机制，把真实的事务实现从事务代码中抽象出来。选择程序控制事务管理还是声明式事务管理，很大程度上是在细粒度控制与简便操作之间做出决定。当你在代码中编写事务时，你能精确控制事务的边界，在你希望的地方精确的开始和结束。典型的情况下，你不需要程序控制事务所提供的细粒度控制，你会选择在上下文定义文件中声明你的事务。
Spring对声明式事务管理的支持是通过它的AOP框架实现的。这样做是非常自然的，因为事务是系统级的，凌驾于应用的主要功能之上的。
在Spring里，事务属性是对事务策略如何应用到方法的描述。这个描述包括：传播行为、隔离级别、只读提示、事务超时间隔
传播行为：
PROPAGATION_MANDATORY:表示该方法必须运行在一个事务中。如果当前事务不存在，将抛出一个异常。
PROPAGATION_NESTED:表示如果当前已经存在一个事务，则该方法应当运行在一个嵌套的事务中。被嵌套的事务可以从当前事务中单独的提交或回滚。如果当前事务不存在，那么它看起来和PROPAGATION_REQUIRED没有两样。
PROPAGATION_NEVER:表示当前的方法不应该运行在一个事务上下文中。如果当前存在一个事务，则会抛出一个异常。
PROPAGATION_NOT_SUPPORTED:表示该方法不应在事务中运行。如果一个现有的事务正在运行中，它将在该方法的运行期间被挂起。
PROPAGATION_REQUIRED:表示当前方法必须运行在一个事务中。如果一个现有的事务正在运行中，该方法将运行在这个事务中。否则的话，要开始一个新的事务。
PROPAGATION_REQUIRES_NEW:表示当前方法必须运行在它自己的事务里。它将启动一个新的事务。如果有事务运行的话，将在这个方法运行期间被挂起。
PROPAGATION_SUPPORTS:表示当前方法不需要事务处理环境，但如果有一个事务已经在运行的话，这个方法也可以在这个事务里运行。
传播规则回答了一个问题：就是新的事务是否要被启动或是被挂起，或者方法是否要在事务环境中运行。
隔离级别：在一个典型的应用中，多个事务并发运行，经常会操作同一个数据来完成它们的任务。并发，虽然是必须的，但会导致下面问题：
1、脏读：脏读发生在一个事务读取了被另一个事务改写但还未提交的数据时。如果这些改变在稍后被回滚，那么第一个事务读取的数据就是无效的。
2、不可重复读：不可重复读发生在一个事务执行相同的查询2次或2次以上，但每一次查询结果都不同时。这通常是由于另一个并发事务在2次查询之间更新了数据。
3、幻读：幻读和不可重复读相似。当一个事务读取几行纪录后，另一个并发事务插入一些记录，幻读就发生了。隔离级别有如下几个：
ISOLATION_DEFAULT:使用后端数据库默认的隔离级别
ISOLATION_READ_UNCOMMITTED:允许你读取还未提交的改变了的数据，可能导致脏读、幻读、不可重复读
ISOLATION_READ_COMMITTED:允许在并发事务已经提交后读取。可防止脏读，但幻读和不可重复读仍可能发生。
ISOLATION_REPEATABLE_READ:对相同字段的多次读取的结果是一致的，除非数据被事务本身改变。可防止脏读和不可重复读，但幻读仍可能发生。
ISOLATION_SERIALIZABLE:完全服从ACID的隔离级别，确保不发生脏读、不可重复读和幻读。这在所有隔离级别中也是最慢的。
只读：如果一个事务只对后端是据库执行读操作，数据库就可能利用事务只读的特性，使用某些优化措施。通过声明一个事务为只读，你就给了后端数据库一个机会，来应用那些它认为合适的优化措施。因为只读的优化措施是在事务启动时由后端数据库实施的，所以，只有将那些具有可能启动新事务的传播行为的方法的事务标记成只读才有意义(PROPAGATION_REQUIRED,PROPAGATION_REQUIRES_NEW和PROPAGATION_NESTED) TransactionProxyFactoryBean参照一个方法的事务属性，决定如何在那个方法上执行事务策略。
<?xml version="1.0" encoding="UTF-8"?>
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>java:comp/env/jdbc/myDatasource</value>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<!-- 这个对象有一个值为courseService的id.当应用从应用上下文里请求一个courseService时，它将得到一个被
TransactionProxyFactoryBean包裹的实例。 -->
<bean id="courseService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<!-- 代理所实现的接口 -->
<property name="proxyInterfaces">
<list>
<value>
com.springinaction.training.service.CourseService
</value>
</list>
</property>
<!-- 被代理的对象 -->
<property name="target">
<ref bean="courseServiceTarget"/>
</property>
<!-- 事务管理器 -->
<property name="transactionManager">
<ref bean="transactionManager"/>
</property>
<!-- 事务的属性源 -->
<property name="transactionAttributeSource">
<ref bean="transactionAttributeSource"/>
</property>
</bean>
<!-- 要知道尽管可以改变MatchAlwaysTransactionAttributeSource的事务属性参数，但它总是返回相同的事务属性，而
不关心参与交易的哪一个方法。当你有一个相对简单的应用，把同样的事务策略应用到所有方法都没问题时，使用MatchAlwaysT
ransactionAttributeSource就相当好。但是，在那些更为复杂的应用中，你很可能需要对不同的方法应用不同的事务策略。在那样
情况下，你需要在应用何种策略的问题上做更多精确的控制。 -->
<bean id="transactionAttributeSource" class="org.springframework.transaction.interceptor.MatchAlwaysTransactionAttributeSource">
<property name="transactionAttribute">
<ref bean="myTransactionAttribute"/>
</property>
</bean>
<!-- 定义事务策略 -->
<bean id="myTransactionAttribute" class="org.springframework.transaction.interceptor.DefaultTransactionAttribute">
<!-- 传播行为 -->
<property name="propagationBehaviorName">
<value>PROPAGATION_REQUIRES_NEW</value>
</property>
<!-- 隔离级别 -->
<property name="isolationLevelName">
<value>ISOLATION_REPEATABLE_READ</value>
</property>
</bean>
</beans>
除了将transactionAttributeSource对象织入到TransactionProxyFactoryBean的transactionAttributeSource属性中外，还有一种简单的方法。发展到现在，TransactionProxyFactoryBean也有一个transactionAttributes属性为transactionProperties.
<?xml version="1.0" encoding="UTF-8"?>
<beans
xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.0.xsd">
<bean id="dataSource" class="org.springframework.jndi.JndiObjectFactoryBean">
<property name="jndiName">
<value>java:comp/env/jdbc/myDatasource</value>
</property>
</bean>
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource">
<ref bean="dataSource"/>
</property>
</bean>
<!-- 这个对象有一个值为courseService的id.当应用从应用上下文里请求一个courseService时，它将得到一个被
TransactionProxyFactoryBean包裹的实例。 -->
<bean id="courseService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
<!-- 代理所实现的接口 -->
<property name="proxyInterfaces">
<list>
<value>
com.springinaction.training.service.CourseService
</value>
</list>
</property>
<!-- 被代理的对象 -->
<property name="target">
<ref bean="courseServiceTarget"/>
</property>
<!-- 事务管理器 -->
<property name="transactionManager">
<ref bean="transactionManager"/>
</property>
<!-- 事务的属性源 -->
<property name="transactionAttributeSource">
<ref bean="transactionAttributeSource"/>
</property>
</bean>
<!-- NameMatchTransactionAttributeSource的properties属性把方法名映射到事务属性描述器上。注意CourseException
用一个负号标记。异常可以用负号或正号标记，当负号异常抛出时，将触发回滚;相反的，正号异常表示事务仍可提交，即使这个异常抛出 -->
<bean id="transactionAttributeSource" class="org.springframework.transaction.interceptor.NameMatchTransactionAttributeSource">
<property name="properties">
<props>
<prop key="enrollStudentInCourse">
PROPAGATION_REQUIRES_NEW,ISOLATION_REPEATABLE_READ,readOnly,
-CourseException
</prop>
<!-- 还可以使用通配符 -->
<prop key="get*">
PROPAGATION_SUPPORTS
</prop>
</props>
</property>
</bean>
</beans>
posted @
2009-11-22 11:43 王永庆 阅读(252) |
评论 (0) |
编辑 收藏 HQL作为Hibernate的查询语言，提供了ANSI SQL面向对象的封装形式。
与Criteria和HQL互为补充，Hibernate也提供了对原生SQL以及存储过程的支持，相对于JDBC的SQL操作，Hibernate提供了更为妥善的封装。代码如下：
package com.testproject.hibernate;
import java.util.Iterator;
import java.util.List;
import org.hibernate.Query;
import org.hibernate.Session;
public class HibernateSqlQuery {
Session session = null;
public void querySql(){
String sql = "select {usr.*} from T_User usr";
List list = session.createSQLQuery(sql).addEntity("usr", TUser.class).list();
Iterator it = list.iterator();
while(it.hasNext()){
TUser user = (TUser)it.next();
}
}
public void queryMappingSql(){
Query query = session.getNamedQuery("queryUser");
query.setParameter("name","Erica");
Iterator it = query.list().iterator();
while(it.hasNext()){
TUser user = (TUser)it.next();
}
}
}
<?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC
"-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<hibernate-mapping>
<class name="com.testproject.hibernate.TUser" table="T_USER">
<id name="id" column="id">
<generator class="native"></generator>
</id>
</class>
<sql-query name="queryUser">
<![CDATA[
select {usr.*} from T_User usr where name=:name
]]>
<return alias = "usr" class="com.testproject.hibernate.TUser"></return>
</sql-query>
<!-- 基于存储过程查询 sql-query节点的callable属性设定为true,指明当前查询基于存储过程定义-->
<sql-query name="getUsersByAge" callable="true">
<return alias="user" class="com.testproject.hibernate.TUser">
<return-property name="id" column="ID"></return-property>
<return-property name="name" column="NAME"></return-property>
<return-property name="age" column="AGE"></return-property>
</return>
{?=call getUsersByAge(?)}
</sql-query>
</hibernate-mapping>
与HQL相同，Native SQL也可以在实体映射文件中进行配置：
posted @
2009-11-21 21:37 王永庆 阅读(235) |
评论 (0) |
编辑 收藏
摘要: 实体Bean包含BMP和CMP两种类型。对BMP实体Bean而言，开发者必须提供各自的数据访问逻辑。为了实现BMP，通常会使用操作数据库的API,比如JDBC.对于CMP实体Bean而言，EJB容器会自动实现数据访问逻辑。这就是CMP的优势所在。通常，只有在应用服务器提供的CMP和目标RDBMS不能满足性能要求时，才去考虑BMP.此时，开发者能够细粒度调整BM...
阅读全文
posted @
2009-11-21 12:32 王永庆 阅读(208) |
评论 (0) |
编辑 收藏