lqxue

常用链接

统计

book

tools

最新评论

#

Print the Stack Trace of the Exception to a String

import java.io.PrintWriter;
import java.io.StringWriter;
public static String getStackTrace(Throwable t)
{
StringWriter sw = new StringWriter();
PrintWriter pw = new PrintWriter(sw, true);
t.printStackTrace(pw);
pw.flush();
sw.flush();
return sw.toString();
}

posted @ 2007-04-17 17:24 lqx 阅读(216) | 评论 (0)编辑 收藏

spring 管理事务时的pointcut语法

 
  1. execution(modifiers-pattern? ret-type-pattern declaring-type-pattern? name-pattern(param-pattern) throws-pattern?) 

其中带问号的modifiers-pattern?(public/protected) 和 declaring-type-pattern? throws-pattern? 可以不填

可见execution(* *..BookManager.save(..))

第一颗* 代表ret-type-pattern 返回值可任意,
*..BookManager 代表任意Pacakge里的BookManager类。
如果写成com.xyz.service.* 则代表com.xyz.service下的任意类
com.xyz.service..* com.xyz.service则代表com.xyz.service及其子package下的任意类
save代表save方法,也可以写save* 代表saveBook()等方法
(..) 匹配0个参数或者多个参数的,任意类型
(x,..) 第一个参数的类型必须是X
(x,,,s,..) 匹配至少4个参数,第一个参数必须是x类型,第二个和第三个参数可以任意,第四个必须是s类型。

注意name-pattern千万不要写成*..*Manager ,这样子的话会把所有第三方类库的Manager比如Spring的PlatformTranstationManager 也加入aop,非常危险。所以最好还是加上项目的package前缀,如org.springside

posted @ 2007-04-17 16:38 lqx 阅读(264) | 评论 (0)编辑 收藏

hibernate集合映射inverse和cascade详解 (转载)

4. hibernate如何根据pojo来更新数据库

4.0 在commit/flush之前,hibernate不会对pojo对象作神秘的处理。
4.0.1 在select查询出pojo时,hibernate根据“字段--属性”的对应关系,用字段的值填充pojo的属性;
然后根据“关系标记”生成sql语句从relationTable中查询出满足条件的relationPojo,并把这些relatinPojo
放到“关系属性”中。这个过程是机械的。

4.0.2 在pojo对象被查出来后,到commit(或flush)之前,它将是一个普通的java对象,hibernate不会做额外的手脚。
比如,不会限制你设置一个属性的值为null或其它任何值
在集合类Set的add(object)操作时, 不会改变object的值,不会检查参数object是否是一个pojo对象
设置mainPojo的一个“桥属性”的值,不会自动设置relationPojo的对应的“桥属性”的值。
执行session.delete(pojo)时,pojo本身没有变化,他的属性值也没有变化。
执行session.save(pojo)时,如果pojo的id不是hibernate或数据库生成,则它的值没有变化。
如果pojo的id是hibernate或数据库生成,则hibernate会把id给pojo设上去。

extend: 对lazy=true的set,hibernate在进行set的操作(调用java.util.Set中声明的方法)时
会先inialize这个set,仅此而已。而inialize仅仅是从数据库中捞出set的数据。
如果一个set已经被inialize了,那么对它进行的操作就是java.util.Set接口中定义的语义。

另外,如果id由hibernate来生成,那么在save(pojo)时,hibernate会改变该pojo,会设置它的id,这
可能改变该pojo的hashCode,详细地讨论见帖《》

mapping文件中标记的某些属性及pojo对象的操作会对数据库操作产生影响,这些影响都是在commit时才会起作用。
而在commit前pojo的状态不受它们的影响。

不过,待commit之时,将由hibernate完全掌控,它好像知道pojo对象从创建到commit这中间的所有变化。


4.01. 关联更新
"关系标记"对应的属性是一个pojo或一个pojo的集合,修改“关系属性”的值能会导致更新mainTable表,也可能会更新relationTable表。

这种更新暂叫“关联更新”。


4.1.inverse属性的作用(假定没有设置cascade属性)
4.1.1 “只有集合标记(set/map/list/array/bag)才有inverse属性”。
————不妨以标记set为例,具体为“一个地区(Address表)的学校(School表)” -- address.schoolSet。

4.1.2 “set的inverse属性决定是否把对set的改动反映到数据库中去。
inverse=false————反映;inverse=true————不反映”
inverse属性默认为false

对<one-to-many>和<many-to-many>子标记,这两条都适用。
不管是对set做什么操作,4.1.2都适用。

4.1.3当inverse=false时,hibernate如何将对set的改动反映到数据库中:

对set的操作主要有:(1)新增元素 address.getSchoolSet().add(oneSchool);
(2)删除元素 address.getSchoolSet().remove(oneSchool);
(3)删除set address.setSchoolSet(null);
(4)设新set address.setSchoolSet( newSchoolSet);
(5)转移set otherSchoolSet = otherAddress.getSchoolSet();
otherAddress.setSchoolSet(null);
address.setSchoolSet(otherSchoolSet);
(6)改变set中元素的属性的值 如果是改变key属性,这会导致异常
如果改变的是普通的属性,则hibernate认为set没有变化(在后面可以看出缘由)。
所以这种情形不予考虑。

改变set后,hibernate对数据库的操作根据是<one-to-many>关系还是<many-to-many>关系而有不同。

对one-to-many,对school set的改动,会改变表SCHOOL中的数据:
#SCHOOL_ID是school表的主键,SCHOOL_ADDRESS是school表中的地址栏位
#表School的外键为SCHOOL_ADDRESS,它对应表Address的主键ADDRESS_ID
(11)insert oneSchool———— sqlInsertRowString:
update SCHOOL set SCHOOL_ADDRESS=? where SCHOOL_ID=?
(仅仅update foreign-key的值。)
(22)delete oneSchool———— sqlDeleteRowString:
update SCHOOL set SCHOOL_ADDRESS=null where SCHOOL_ID=?
(很奇怪,把foreign-key设置为null不知道有什么实际意义?)
(33)delete 属于某一address的所有school ————sqlDeleteString:
update SCHOOL set SCHOOL_ADDRESS=null where SCHOOL_ADDRESS=?
(44)update ————sqlUpdateRowString:"", no need

对many-to-many,对school set的改动,会改变关系表ADDRESS_SCHOOL中的数据:
#“地区————学校”的关系为多对多的关系有点牵强,只是为了方便与上面的one-to-many作比较
#假设有一个关系表ADDRESS_SCHOOL,有两个字段ADDRESS_ID, SCHOOL_ID,
#这两个字段分别对应ADDRESS和SCHOOL两表的key
(11)insert的SQL语句为: insert into ADDRESS_SCHOOL(ADDRESS_ID, SCHOOL_ID)
values(?,?)
(22)delete的SQL语句为: delete from ADDRESS_SCHOOL
where ADDRESS_ID=? AND SCHOOL_ID=?
(33)delete all的SQL语句为: delete from ADDRESS_SCHOOL
where ADDRESS_ID=?
(44)update的sql语句为 ————sqlUpdateRowString:
update ADDRESS_SCHOOL set ADDRESS_ID=?
where ADDRESS_ID=? AND SCHOOL_ID=?

对set的操作(1),hibernate会执行(11)sqlInsertRowString
对set的操作(2),hibernate会执行(22)sqlDeleteRowString
对set的操作(3),hibernate会执行(33)sqlDeleteString
对set的操作(4),老的schoolSet因为没有所属的address,所以被全部delete掉,即先执行(33)sqlDeleteString
然后新增新的schoolSet,即再执行sqlInsertRowString
对set的操作(5),实际上就是将set从一个pojo转移到另一pojo:
首先,执行sqlDeleteString,删除掉otherAddress所属的school
然后,执行sqlDeleteString,删除掉address原先的school
最后,执行sqlInsertRowString,将otherSchoolSet新增给address

总结:(1)对one-to-many而言,改变set,会让hibernate执行一系列的update语句, 不会delete/insert数据
(2)对many-to-many而言,改变set,只修改关系表的数据,不会影响many-to-many的另一方。
(3)虽然one-to-many和many-to-many的数据库操作不一样,但目的都是一个:维护数据的一致性。执行的sql都
只涉及到“桥字段”,不会考虑或改变其他的字段,所以对set的操作(6)是没有效果地。
extend:对list,可能还会维护index字段。

4.1.4 “inverse与cascade没有什么关系,互无牵扯。”
commit后,这两个属性发挥作用的时机不同,hibernate会根据对pojo对象的改动,及cascade属性的设置,
生成一系列的Action,比如UpdateAction,DeleteAction,InsertAction等,每个Action都有execute方法以执行对应的sql语句。
待所有这些Action都生成好了后,hibernate再一起执行它们,在执行sql前,inverse属性起作用,
当inverse=true时,不执行sql;当inverse=false时,执行sql。

4.1.5 inverse的默认值为false,所以inverse属性默认会进行“关联更新”。

4.1.6 建议:只对set + many-to-many设置inverse=false,其他的标记不考虑inverse属性。
  糟糕的是,不设置inverse属性时,inverse默认为false。

4.2. 级联(cascade)属性的作用:
4.2.1 只有“关系标记”才有cascade属性:many-to-one,one-to-one ,any,
set(map, bag, idbag, list, array) + one-to-many(many-to-many)

4.2.2 级联指的是当主控方执行操作时,关联对象(被动方)是否同步执行同一操作。
pojo和它的关系属性的关系就是“主控方 -- 被动方”的关系,如果关系属性是一个set,那么被动方就是set中的一个一个元素,。
比如:学校(School)有三个属性:地区(Address),校长(TheMaster)和学生(Set, 元素为Student)
执行session.delete(school)时,级联决定是否执行session.delete(Address),session.delete(theMaster),
是否对每个aStudent执行session.delete(aStudent)。

extend:这点和inverse属性是有区别的。见4.3.

4.2.3 一个操作因级联cascade可能触发多个关联操作。前一个操作叫“主控操作”,后一个操作叫“关联操作”。
cascade属性的可选值:
all : 所有情况下均进行关联操作。
none:所有情况下均不进行关联操作。这是默认值。
save-update:在执行save/update/saveOrUpdate时进行关联操作。
delete:在执行delete时进行关联操作。

具体执行什么“关联操作”是根据“主控操作”来的:
“主控操作”       “关联操作”
session.saveOrUpdate --> session.saveOrUpdate (执行saveOrUpdate实际上会执行save或者update)
session.save ----> session.saveOrUpdate
session.udpate --> session.saveOrUpdate
session.delete --> session.delete

4.2.4 主控操作和关联操作的先后顺序是“先保存one,再保存many;先删除many,再删除one;先update主控方,再update被动方”
对于one-to-one,当其属性constrained="false"(默认值)时,它可看作one-to-many关系;
  当其属性constrained="true"时,它可看作many-to-one关系;
对many-to-many,它可看作one-to-many。

比如:学校(School)有三个属性:地区(Address),校长(TheMaster,其constrained="false")和学生(Set, 元素为Student)
当执行session.save(school)时,
实际的执行顺序为:session.save(Address);
session.save(school);
session.save(theMaster);
for( 对每一个student ){
session.save(aStudent);
}

当执行session.delete(school)时,
实际的执行顺序为:session.delete(theMaster);
for( 对每一个student ){
session.delete(aStudent);
}
session.delete(school);
session.delete(Address);

当执行session.update(school)时,
实际的执行顺序为:session.update(school);
session.saveOrUpdate(Address);
session.saveOrUpdate(theMaster);
for( 对每一个student ){
session.saveOrUpdate(aStudent);
}
注意:update操作因级联引发的关联操作为saveOrUpdate操作,而不是update操作。
saveOrUpdate与update的区别是:前者根据操作对象是保存了还是没有保存,而决定执行update还是save

extends: 实际中,删除学校不会删除地区,即地区的cascade一般设为false
另外,many-to-many关系很少设置cascade=true,而是设置inverse=false。这个反映了cascade和inverse的区别。见4.3

4.2.6 cascade的默认值为false,所以inverse属性默认会进行“关联更新”。

4.2.7 总结:级联(cascade)就是操作一个对象时,对它的属性(其cascade=true)也进行这个操作。


4.3 inverse和cascade的比较
这两个属性本身互不影响,但起的作用有些类似,都能引发对关系表的更新。

4.3.1 inverse只对set+one-to-many(或many-to-many)有效,对many-to-one, one-to-one无效。
cascade对关系标记都有效。

4.3.2 inverse对集合对象整体起作用,cascade对集合对象中的一个一个元素起作用,如果集合为空,那么cascade不会引发关联操作。
比如将集合对象置为null, school.setStudentSet(null)
inverse导致hibernate执行:udpate STUDENT set SCHOOL_ID=null where SCHOOL_ID=?
cascade则不会执行对STUDENT表的关联更新, 因为集合中没有元素。

再比新增一个school, session.save(school)
inverse导致hibernate执行:
for( 对(school的每一个student ){
udpate STUDENT set SCHOOL_ID=? where STUDENT_ID=? //将学生的school_id改为新的school的id
}
cascade导致hibernate执行:
for( 对school的每一个student ){
session.save(aStudent); //对学生执行save操作
}

extends:如果改变集合中的部分元素(比如新增一个元素),
inverse: hibernate先判断哪些元素改变了,对改变的元素执行相应的sql
cascade: 它总是对集合中的每个元素执行关联操作。
(在关联操作中,hibernate会判断操作的对象是否改变)

4.3.2 两个起作用的时机不同:
cascade:在对主控方操作时,级联发生。
inverse: 在flush时(commit会自动执行flush),对session中的所有set,hibernate判断每个set是否有变化,
对有变化的set执行相应的sql,执行之前,会有个判断:if( inverse == true ) return;

可以看出cascade在先,inverse在后。

4.3.3 inverse 对set + one-to-many 和 set + many-to-many 起的作用不同。hibernate生成的sql不同。
对one-to-many,hibernate对many方的数据库表执行update语句。
对many-to-many, hibernate对关系表执行insert/update/delte语句,注意不是对many方的数据库表而是关系表。

cascase 对set都是一致的,不管one-to-many还是many-to-many。都简单地把操作传递到set中的每个元素。所以它总是更新many
方的数据库表。

4.3.4 建议:只对set + many-to-many设置inverse=false,其他的标记不考虑inverse属性,都设为inverse=true。
 
  对cascade,一般对many-to-one,many-to-many,constrained=true的one-to-one 不设置级联删除。

引自:http://bbs.tech.ccidnet.com/simple/index.php?t144447.html

posted @ 2007-04-13 13:19 lqx 阅读(395) | 评论 (0)编辑 收藏

Spring AOP处理日志

Spring AOP处理日志

AOP正在成为软件开发的下一个圣杯。使用AOP,你可以将处理aspect的代码注入主程序,
通常主程序的主要目的并不在于处理这些aspect。AOP可以防止代码混乱。 为了理解AOP
如何做到这点,考虑一下记日志的工作。日志本身不太可能是你开发的主程序的主要任务。
如果能将“不可见的”、通用的日志代码注入主程序中,那该多好啊。AOP可以帮助你做到。
Spring framework是很有前途的AOP技术。作为一种非侵略性的,轻型的AOP framework,你
无需使用预编译器或其他的元标签,便可以在Java程序中使用它。这意味着开发团队里只需
一人要对付AOP framework,其他人还是象往常一样编程。 AOP是很多直觉难以理解的术语的根源。
幸运的是,你只要理解三个概念,就可以编写AOP模块。这三个概念是:advice,pointcut和advisor。
advice是你想向别的程序内部不同的地方注入的代码。pointcut定义了需要注入advice的位置,通常
是某个特定的类的一个public方法。advisor是pointcut和advice的装配器,是将advice注入主程序
中预定义位置的代码。

既然我们知道了需要使用advisor向主要代码中注入“不可见的”advice,让我们实现一个Spring AOP的例子。
在这个例子中,我们将实现一个before advice,这意味着advice的代码在被调用的public方法开始前被执行。
以下是这个before advice的实现代码:

代码:
package com.company.springaop.test;

import java.lang.reflect.Method;
import org.springframework.aop.MethodBeforeAdvice;

public class TestBeforeAdvice implements MethodBeforeAdvice { //这里还有after,Exception,around等Advice
/**
*before 是在方法执行之前执行advice的内容,around是在方法执行之前和之后都得到了执行
*Exception是抛出异常的时候,可以使用aop的方法来统一处理业务的异常。
×在编程的时候,可以由专门的人处理业务的异常,其它人还是一样的编程,不用考虑业务类异常的处理。
*/

  public void before(Method m, Object[] args, Object target)
  throws Throwable { //这里能用反射?
    System.out.println("Hello world! (by "
        + this.getClass().getName()
        + ")");
  }
}
 


接 口MethodBeforeAdvice只有一个方法before需要实现,它定义了advice的实现。before方法共用三个参数,它们提供了相当 丰富的信息。参数Method m是advice开始后执行的方法。方法名称可以用作判断是否执行代码的条件。Object[] args是传给被调用的public方法的参数数组。当需要记日志时,参数args和被执行方法的名称,都是非常有用的信息。你也可以改变传给m的参数, 但要小心使用这个功能;编写最初主程序的程序员并不知道主程序可能会和传入参数的发生冲突。Object target是执行方法m对象的引用。

在下面的BeanImpl类中,每个public方法调用前,都会执行advice:

代码:
package com.company.springaop.test;

public class BeanImpl implements Bean {

  public void theMethod() {
    System.out.println(this.getClass().getName()
        + "." + new Exception().getStackTrace()[0].getMethodName()
        + "()"
        + " says HELLO!");
  }
}


类BeanImpl实现了下面的接口Bean:

代码:
package com.company.springaop.test;

public interface Bean {
  public void theMethod();
}

 

虽然不是必须使用接口,但面向接口而不是面向实现编程是良好的编程实践,Spring也鼓励这样做。

pointcut和advice通过配置文件来实现,因此,接下来你只需编写主方法的Java代码:
代码:


package com.company.springaop.test;

import org.springframework.context.ApplicationContext;
import org.springframework.context.support.FileSystemXmlApplicationContext;

public class Main {

  public static void main(String[] args) {
    //Read the configuration file
    ApplicationContext ctx
        = new FileSystemXmlApplicationContext("springconfig.xml");

    //Instantiate an object
    Bean x = (Bean) ctx.getBean("bean");

    //Execute the public method of the bean (the test)
    x.theMethod();
  }
}

 

我们从读入和处理配置文件开始,接下来马上要创建它。这个配置文件将作为粘合程序不同部分的“胶水”。读入和处理配置文件后,我们会得到一个创建工厂ctx。任何一个Spring管理的对象都必须通过这个工厂来创建。对象通过工厂创建后便可正常使用。

仅仅用配置文件便可把程序的每一部分组装起来。
代码:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE beans PUBLIC  "-//SPRING//DTD BEAN//EN" "http://www.springframework.org/dtd/spring-beans.dtd">

<beans>
  <!--CONFIG-->
  <bean id="bean" class="org.springframework.aop.framework.ProxyFactoryBean">
    <property name="proxyInterfaces">
      <value>com.company.springaop.test.Bean</value>
    </property>
    <property name="target">
      <ref local="beanTarget"/>
    </property>
    <property name="interceptorNames">
      <list>
        <value>theAdvisor</value>
      </list>
    </property>
  </bean>

  <!--CLASS-->
  <bean id="beanTarget" class="com.company.springaop.test.BeanImpl"/>

  <!--ADVISOR-->
  <!--Note: An advisor assembles pointcut and advice-->
  <bean id="theAdvisor" class="org.springframework.aop.support.RegexpMethodPointcutAdvisor">
    <property name="advice">
      <ref local="theBeforeAdvice"/>
    </property>
    <property name="pattern"> //pointcut?
      <value>com\.company\.springaop\.test\.Bean\.theMethod</value>
    </property>
  </bean>

  <!--ADVICE-->
  <bean id="theBeforeAdvice" class="com.company.springaop.test.TestBeforeAdvice"/>
</beans>
 


四个bean定义的次序并不重要。我们现在有了一个advice,一个包含了正则表达式pointcut的advisor,
一个主程序类和一个配置好的接口,通过工厂ctx,这个接口返回自己本身实现的一个引用。 BeanImpl
和TestBeforeAdvice都是直接配置。我们用一个唯一的ID创建一个bean元素,并指定了一个实现类。这
就是全部的工作。advisor通过Spring framework提供的一个RegexMethodPointcutAdvisor类来实现。我
们用advisor的一个属性来指定它所需的advice-bean。第二个属性则用正则表达式定义了pointcut,确保
良好的性能和易读性。 最后配置的是bean,它可以通过一个工厂来创建。bean的定义看起来比实际上要
复杂。bean是ProxyFactoryBean的一个实现,它是Spring framework的一部分。这个bean的行为通过一下
的三个属性来定义:

 


属性proxyInterface定义了接口类。

属性target指向本地配置的一个bean,这个bean返回一个接口的实现。

属性interceptorNames是唯一允许定义一个值列表的属性。这个列表包含所有需要在beanTarget上执行的advisor。

注意,advisor列表的次序是非常重要的。

 

Spring工具

虽然你可以手工修改Ant构建脚本,但使用SpringUI(译注:SpringUI现在是Spring framework的一部分,并改名
为spring-ide),使用Spring AOP变得很简单,只要点点鼠标即可。你可以把SpringUI安装成Eclipse的一个plug-in。
然后,你只需在你的project上右击鼠标,并选择“add Spring Project Nature”。在project属性中,你可以在“Spring
Project”下添加Spring配置文件。在编译前把下面的类库加入project:aopalliance.jar,commons-logging.jar,
jakarta-oro-2.0.7.jar和spring.jar。运行程序时你会看到下面的信息:

... (logging information)
Hello world! (by com.company.springaop.test.TestBeforeAdvice)
com.company.springaop.test.BeanImpl.theMethod() says HELLO!


优点和缺点

Spring比起其他的framework更有优势,因为除了AOP以外,它提供了更多别的功能。
作为一个轻型framework,它在J2EE不同的部分都可以发挥作用。因此,即使不想使用Spring AOP,
你可能还是想使用Spring。另一个优点是,Spring并不要求开发团队所有的人员都会用它。
学习Spring应该从Spring reference的第一页开始。读了本文后,你应该可以更好地理解Spring reference了。
Spring唯一的缺点是缺乏更多的文档,但它的mailing list是个很好的补充,而且会不断地出现更多的文档。


(引自http://blogger.org.cn/blog/more.asp?name=littcricket&id=18341)




posted @ 2007-04-09 16:23 lqx 阅读(941) | 评论 (0)编辑 收藏

Hibernate Transaction

http://www.blogjava.net/goingmm/archive/2005/11/28/21642.html

posted @ 2007-04-06 17:21 lqx 阅读(101) | 评论 (0)编辑 收藏

(转)Hibernate Transaction

Hibernate Transaction

posted @ 2007-04-06 17:20 lqx 阅读(135) | 评论 (0)编辑 收藏

数据库事务和锁

简述

    关系型数据库有四个显著的特征,即安全性、完整性、并发性和监测性。数据库的安全性就是要保证数据库中数据的安全,防止未授权用户随意修改数据库中的数 据,确保数据的安全。在大多数数据库管理系统中,主要是通过许可来保证数据库的安全性。完整性是数据库的一个重要特征,也是保证数据库中的数据切实有效、 防止错误、实现商业规则的一种重要机制。在数据库中,区别所保存的数据是无用的垃圾还是有价值的信息,主要是依据数据库的完整性是否健全。在SQL Server 7.0中,数据的完整性是通过一系列逻辑来保障的,这些逻辑分为三个方面,即实体完整性、域完整性和参考完整性。对任何系统都可以这样说,没有监测,就没 有优化。这句话用在数据库管理系统方面,也是切合实际的。只有通过对数据库进行全面的性能监测,也才能发现影响系统性能的因素和瓶颈,才能针对瓶颈因素, 采取切合实际策略,解决问题,提高系统的性能。并发性也是一个非常重要的概念,它是用来解决多个用户对同一数据进行操作时的问题。特别是对于网络数据库来 说,这个特点更加突出。提高数据库的处理速度,单单依靠提高计算机的物理速度是不够的,还必须充分考虑数据库的并发性问题,提高数据库并发性的效率。那么 如何保证并发性呢?在这个面向下一世纪的数据库产品SQL Server 7.0中,通过使用事务和锁机制,解决了数据库的并发性问题。

事 务和锁是两个紧密联系的概念事务就是一个单元的工作,包括一系列的操作这些操作要么全部成功,要么全部失败。事务确保多个数据的修改作为一个单元来处 理。例如,在银行业务中,有一条记帐原则,即有借有贷,借贷相等。那么为了保证这种原则,就得有确保借和贷的登记要么同时成功,要么同时失败。如果出现只 记录了借,或者只记录了贷,那么就违反了记帐原则,就会出现记错帐的情况。SQL Server通过支持事务机制管理多个事务,保证事务的一致性。事务使用锁,防止其他用户修改另外一个还没有完成的事务中的数据。对于多用户系统来说,锁 机制是必须的。在SQL Server 7.0中,使用事务日志来保证修改的完整性和可恢复性。

    SQL Server有多种锁,允许事务锁定不同的资源。锁就是保护指定的资源,不被其他事务操作。为了最小化锁的成本,SQL Server自动地以与任务相应等级的锁来锁定资源对象。锁定比较小的对象,例如锁定行,虽然可以提高并发性,但是却有较高的开支,因为如果锁定许多行, 那么需要占有更多的锁。锁定比较大的对象,例如锁定表,会大大降低并发性,因为锁定整个表就限制了其他事务访问该表的其他部分,但是成本开支比较低,因为 只需维护比较少的锁。

    事务和锁具有以下特点:

  • 事务是一个单元的工作,要么全做,要么全不做
  • 事务保证操作的一致性和可恢复性
  • 每一条Transact-SQL语句都可以是一个事务
  • 实际使用的事务是用户定义的事务,它包括一系列操作或者语句
  • 在多服务器环境中,使用用户定义的分布式事务,保证操作的一致性
  • 锁是保证并发控制的手段
  • 可以锁定的资源包括行、页、簇、表和数据库
  • 锁的类型主要包括共享锁和排它锁
  • 特殊类型的锁包括意图锁、修改锁和模式锁
  • 共享锁允许其他事务继续使用锁定的资源
  • 排它锁只允许一个事务访问数据
  • 系统本身可以处理死锁
  • 用户可以根据实际情况定制锁的一些特征

事务

事务的定义

    事务是指一个单元的工作,这些工作要么全做,要么全部不做。作为一个逻辑单元,必须具备四个属性:原子性、一致性、独立性和持久性。原子性是指事务必须是 一个自动的单元工作,要么执行全部数据的修改,要么全部数据的修改都不执行。一致性是指当事务完成时,必须使所有数据都具有一致的状态。在关系型数据库 中,所有的规则必须应用到事务的修改上,以便维护所有数据的完整性。所有的内部数据结构,例如树状的索引与数据之间的链接,在事务结束之后,必须保证正 确。独立性是指并行事务的修改必须与其他并行事务的修改相互独立。一个事务看到的数据要么是另外一个事务修改这些事务之前的状态,要么是第二个事务已经修 改完成的数据,但是这个事务不能看到正在修改的数据。这种特征也称为串行性。持久性是指当一个事务完成之后,它的影响永久性的产生在系统中,也就是这种修 改写到了数据库中。

    事务机制保证一组数据的修改要么全部执行,要么全部不执行。SQL Server使用事务保证数据的一致性和确保在系统失败时的可恢复性。事务是一个可以恢复的单元的工作,由一条或者多条Transact-SQL语句组 成,可以影响到表中的一行或者多行数据。事务打开以后,直到事务成功完成之后提交为止,或者到事务执行失败全部取消或者滚回去为止。



悲观锁定 假定任何时刻存取数据时,都可能有另一个客户也正在存取同一笔数据,因而对数据采取了数据库层次的锁定状态,在锁定的时间内其它的客户不能对资 料进行存取,对于单机或小系统而言,这并不成问题,然而如果是在网络上的系统,同时间会有许多联机,如果每一次读取数据都造成锁定,其后继的存取就必须等 待,这将造成效能上的问题,造成后继使用者的长时间等待。
乐观锁定(optimistic locking)则乐观的认为资料的存取很少发生同时存取的问题,因而不作数据库层次上的锁定,为了维护正确的数据,乐观锁定使用应用程序上的逻辑实现版本控制的解决。
例如若有两个客户端,A客户先读取了账户余额1000元,之后B客户也读取了账户余额1000元的数据,A客户提取了500元,对数据库作了变更,此时 数据库中的余额为500元,B客户也要提取300元,根据其所取得的资料,1000-300将为700余额,若此时再对数据库进行变更,最后的余额就会不 正确。
在不实行悲观锁定策略的情况下,数据不一致的情况一但发生,有几个解决的方法,一种是先更新为主,一种是后更新的为主,比较复杂的就是检查发生变动的数据来实现,或是检查所有属性来实现乐观锁定。

 

posted @ 2007-04-06 16:57 lqx 阅读(391) | 评论 (0)编辑 收藏

(转载)关于hibernate中的锁机制

前几天看到GOING MM关于Hibernate Transaction 的描述,这里顺便转载一篇hiberntae中锁机制的文章:

   悲观锁定 假定任何时刻存取数据时,都可能有另一个客户也正在存取同一笔数据,因而对数据采取了数据库层次的锁定状态,在锁定的时间内其它的客户不能对资 料进行存取,对于单机或小系统而言,这并不成问题,然而如果是在网络上的系统,同时间会有许多联机,如果每一次读取数据都造成锁定,其后继的存取就必须等 待,这将造成效能上的问题,造成后继使用者的长时间等待。
 乐观锁定(optimistic locking)则乐观的认为资料的存取很少发生同时存取的问题,因而不作数据库层次上的锁定,为了维护正确的数据,乐观锁定使用应用程序上的逻辑实现版本控制的解决。
例如若有两个客户端,A客户先读取了账户余额1000元,之后B客户也读取了账户余额1000元的数据,A客户提取了500元,对数据库作了变更,此时 数据库中的余额为500元,B客户也要提取300元,根据其所取得的资料,1000-300将为700余额,若此时再对数据库进行变更,最后的余额就会不 正确。
 在不实行悲观锁定策略的情况下,数据不一致的情况一但发生,有几个解决的方法,一种是先更新为主,一种是后更新的为主,比较复杂的就是检查发生变动的数据来实现,或是检查所有属性来实现乐观锁定。
 Hibernate 中透过版本号检查来实现后更新为主,这也是Hibernate所推荐的方式,在数据库中加入一个VERSON栏记录,在读取数据时连 同版本号一同读取,并在更新数据时递增版本号,然后比对版本号与数据库中的版本号,如果大于数据库中的版本号则予以更新,否则就回报错误。
 以刚 才的例子,A客户读取账户余额1000元,并连带读取版本号为5的话,B客户此时也读取账号余额1000元,版本号也为5,A客户在领款后账户余额 为500,此时将版本号加1,版本号目前为6,而数据库中版本号为5,所以予以更新,更新数据库后,数据库此时余额为500,版本号为6,B客户领款后要 变更数据库,其版本号为5,但是数据库的版本号为6,此时不予更新,B客户数据重新读取数据库中新的数据并重新进行业务流程才变更数据库。
 以Hibernate实现版本号控制锁定的话,我们的对象中增加一个version属性,例如:

public class Account {

    private int version;

    ....

 

    public void setVersion(int version) {

        this.version = version;

    }

 

    public int getVersion() {

        return version;

    }

    ....

}


而在映像文件中,我们使用optimistic-lock属性设定version控制,<id>属性栏之后增加一个<version>标签,例如:

<hibernate-mapping>

    <class name="onlyfun.caterpillar.Account" talble="ACCOUNT"

           optimistic-lock="version">

        <id...../>

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

 

         ....

 

    </class>

</hibernate-mapping>


 设定好版本控制之后,在上例中如果B 客户试图更新数据,将会引发StableObjectStateException例外,我们可以捕捉这个例外,在处理中重新读取数据库中的数据,同时将 B客户目前的数据与数据库中的数据秀出来,让B客户有机会比对不一致的数据,以决定要变更的部份,或者您可以设计程 式自动读取新的资料,并重复扣款业务流程,直到数据可以更新为止,这一切可以在背景执行,而不用让您的客户知道。


  悲观锁定
在多个客户端可能读取同一笔数据或同时更新一笔数据的情况下,必须要有访问控制的手段,防止同一个数据被修改而造成混乱,最简单的手段就是对数据进行锁定,在自己进行数据读取或更新等动作时,锁定其它客户端不能对同一笔数据进行任何的动作。
 悲观锁定(Pessimistic Locking)一如其名称所示,悲观的认定每次资料存取时,其它的客户端也会存取同一笔数据,因此对该笔数据进行锁定,直到自己操作完成后解除锁定。

 悲观锁定通常透过系统或数据库本身的功能来实现,依赖系统或数据库本身提供的锁定机制,Hibernate即是如此,我们可以利用Query或Criteria的setLockMode()方法来设定要锁定的表或列(row)及其锁定模式,锁定模式有以下的几个:

  • LockMode.WRITE:在insert或update时进行锁定,Hibernate会在save()方法时自动获得锁定。
  • LockMode.UPGRADE:利用SELECT … FOR UPDATE进行锁定。
  • LockMode.UPGRADE_NOWAIT:利用SELECT … FOR UPDATE NOWAIT进行锁定,在Oracle环境下使用。
  • LockMode.READ:在读取记录时Hibernate会自动获得锁定。
  • LockMode.NONE:没有锁定。

 也可以在使用Session的load()或是lock()时指定锁定模式以进行锁定。
 如果数据库不支持所指定的锁定模式,Hibernate会选择一个合适的锁定替换,而不是丢出一个例外(Hibernate参考手册10.6)。

  原文出处:http://blog.csdn.net/chho/archive/2005/01.aspx

posted @ 2007-04-06 16:13 lqx 阅读(177) | 评论 (0)编辑 收藏

为什么在hibernate中用list影射one-to-many时,在查询数据时,经常有null值

 Learned a little this weekend - Bag vs List in Hibernate.  I was troubled since i really wanted to have a Java ArrayList in my object so i could index in my jsp and iterate over the list in an update form.  Using a Hibernate Set left me unable to index.  A Hibernate List left the Java ArrayList populated using the primary key - if the keys were 0,1,2,... that would have been ok.  But i only needed a few items from the database in my ArrayList and since the Hibernate List maintains the position of the object in the ArrayList equal to the position in the database the technique was leaving holes in my ArrayList of nulls.  Of course this was not what i wanted.  Now this may be explained in the documentation but after reading it twice i did not fully understand the Hibernate List.  Over the weekend i read the book Hibernate in Action and discovered the Hibernate Bag and it solved my problem.  I can use a Java ArrayList that is loaded simply by adding new objects to the beginning of the ArrayList.

posted @ 2007-04-05 16:50 lqx 阅读(3066) | 评论 (1)编辑 收藏

Open Session In View

http://www.54bk.com/user1/2690/archives/2006/2006122116259.html

Open Session In View解决session.close问题
ssuupv 发表于 2006-12-21 16:25:00
  在没有使用Spring提供的Open Session In View情况下,因需要在service(or Dao)层里把session关闭,所以lazy loading true的话,要在应用层内把关系集合都初始化,如 company.getEmployees(),否则Hibernatesession already closed Exception;    Open Session In View提供了一种简便的方法,较好地解决了lazy loading问题.

    它有两种配置方式OpenSessionInViewInterceptorOpenSessionInViewFilter(具体参看SpringSide),功能相同,只是一个在web.xml配置,另一个在application.xml配置而已。

    Open Session In Viewrequestsession绑定到当前thread期间一直保持hibernate sessionopen状态,使sessionrequest的整个期间都可以使用,如在View层里PO也可以lazy loading数据,如 ${ company.employees }。当View 层逻辑完成后,才会通过FilterdoFilter方法或InterceptorpostHandle方法自动关闭session

                        
OpenSessionInViewInterceptor配置
  1. <beans>
  2. <bean name="openSessionInViewInterceptor"
  3. class="org.springframework.orm.hibernate3.support.OpenSessionInViewInterceptor">
  4. <property name="sessionFactory">
  5. <ref bean="sessionFactory"/>
  6. </property>
  7. </bean>
  8. <bean id="urlMapping"
  9. class="org.springframework.web.servlet.handler.SimpleUrlHandlerMapping">
  10. <property name="interceptors">
  11. <list>
  12. <ref bean="openSessionInViewInterceptor"/>
  13. </list>
  14. </property>
  15. <property name="mappings">
  16. ...
  17. </property>
  18. </bean>
  19. ...
  20. </beans>
                        
OpenSessionInViewFilter配置
  1. <web-app>
  2. ...
  3. <filter>
  4. <filter-name>hibernateFilter</filter-name>
  5. <filter-class>
  6. org.springframework.orm.hibernate3.support.OpenSessionInViewFilter
  7. </filter-class>
  8. <!-- singleSession默认为true,若设为false则等于没用OpenSessionInView -->
  9. <init-param>
  10. <param-name>singleSession</param-name>
  11. <param-value>true</param-value>
  12. </init-param>
  13. </filter>
  14. ...
  15. <filter-mapping>
  16. <filter-name>hibernateFilter</filter-name>
  17. <url-pattern>*.do</url-pattern>
  18. </filter-mapping>
  19. ...
  20. </web-app>

很多人在使用OpenSessionInView过程中提及一个错误:

                        
  1. org.springframework.dao.InvalidDataAccessApiUsageException: Write operations
  2. are not allowed in read-only mode (FlushMode.NEVER) - turn your Session into
  3. FlushMode.AUTO or remove 'readOnly' marker from transaction definition

看看OpenSessionInViewFilter里的几个方法

                        
  1. protected void doFilterInternal(HttpServletRequest request,
    HttpServletResponse response,FilterChain filterChain)
    throws ServletException, IOException {
     SessionFactory sessionFactory = lookupSessionFactory();
     logger.debug("Opening Hibernate Session in OpenSessionInViewFilter");
     Session session = getSession(sessionFactory);
     TransactionSynchronizationManager.bindResource(
      sessionFactory, new SessionHolder(session));
     try {
      filterChain.doFilter(request, response);
     }
     finally {
     TransactionSynchronizationManager.unbindResource(sessionFactory);
     logger.debug("Closing Hibernate Session in OpenSessionInViewFilter");
     closeSession(session, sessionFactory);
     }
    }





     
  2. protected Session getSession(SessionFactory sessionFactory)
    throws DataAccessResourceFailureException {
     Session session = SessionFactoryUtils.getSession(sessionFactory, true);
     session.setFlushMode(FlushMode.NEVER);
     return session;
    }

  3. protected
    void closeSession(Session session, SessionFactory sessionFactory)
    throws CleanupFailureDataAccessException {
     SessionFactoryUtils.closeSessionIfNecessary(session, sessionFactory);
    }

     可以看到OpenSessionInViewFilter在getSession的时候,会把获取回来的session的flush mode 设为FlushMode.NEVER。然后把该sessionFactory绑定到TransactionSynchronizationManager,使request的整个过程都使用同一个session,在请求过后再接除该sessionFactory的绑定,最后closeSessionIfNecessary根据该session是否已和transaction绑定来决定是否关闭session。在这个过程中,若HibernateTemplate 发现自当前session有不是readOnly的transaction,就会获取到FlushMode.AUTO Session,使方法拥有写权限。

                        
  1. public static void closeSessionIfNecessary(Session session, SessionFactory sessionFactory)
  2. throws CleanupFailureDataAccessException {
  3. if (session == null ||
    TransactionSynchronizationManager.hasResource(sessionFactory)) {
  4. return;
  5. }
  6. logger.debug("Closing Hibernate session");
  7. try {
  8. session.close();
  9. }
  10. catch (JDBCException ex) {
  11. // SQLException underneath
  12. throw new CleanupFailureDataAccessException("Could not close Hibernate session", ex.getSQLException());
  13. }
  14. catch (HibernateException ex) {
  15. throw new CleanupFailureDataAccessException("Could not close Hibernate session", ex);
  16. }
  17. }

    也即是,如果有不是readOnly的transaction就可以由Flush.NEVER转为Flush.AUTO,拥有insert,update,delete操作权限,如果没有transaction,并且没有另外人为地设flush model的话,则doFilter的整个过程都是Flush.NEVER。所以受transaction保护的方法有写权限,没受保护的则没有。

                        
采用spring的事务声明,使方法受transaction控制
  1.   <bean id="baseTransaction"
    class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
              abstract="true">
            <property name="transactionManager" ref="transactionManager"/>
            <property name="proxyTargetClass" value="true"/>
            <property name="transactionAttributes">
                <props>
                    <prop key="get*">PROPAGATION_REQUIRED,readOnly</prop>
                    <prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
                    <prop key="load*">PROPAGATION_REQUIRED,readOnly</prop>
                    <prop key="save*">PROPAGATION_REQUIRED</prop>
                    <prop key="add*">PROPAGATION_REQUIRED</prop>
                    <prop key="update*">PROPAGATION_REQUIRED</prop>
                    <prop key="remove*">PROPAGATION_REQUIRED</prop>
                </props>
            </property>
        </bean>

  2.     <bean id="userService" parent="baseTransaction">
            <property name="target">
                <bean class="com.phopesoft.security.service.impl.UserServiceImpl"/>
            </property>
        </bean>

    对于上例,则以save,add,update,remove开头的方法拥有可写的事务,如果当前有某个方法,如命名为importExcel(),则因没有transaction而没有写权限,这时若方法内有insert,update,delete操作的话,则需要手动设置flush model为Flush.AUTO,如

                                
    1. session.setFlushMode(FlushMode.AUTO);
    2. session.save(user);
    3. session.flush();

         尽管Open Session In View看起来还不错,其实副作用不少。看回上面OpenSessionInViewFilter的doFilterInternal方法代码,这个方法实际上是被父类的doFilter调用的,因此,我们可以大约了解的OpenSessionInViewFilter调用流程: request(请求)->open session并开始transaction->controller->View(Jsp)->结束transaction并close session.

         一切看起来很正确,尤其是在本地开发测试的时候没出现问题,但试想下如果流程中的某一步被阻塞的话,那在这期间connection就一直被占用而不释放。最有可能被阻塞的就是在写Jsp这步,一方面可能是页面内容大,response.write的时间长,另一方面可能是网速慢,服务器与用户间传输时间久。当大量这样的情况出现时,就有连接池连接不足,造成页面假死现象。

    Open Session In View是个双刃剑,放在公网上内容多流量大的网站请慎用。


    阅读全文(302) | 回复(0) | 引用通告(638) | 编辑
     

    posted @ 2007-04-03 08:58 lqx 阅读(240) | 评论 (0)编辑 收藏

    仅列出标题
    共18页: First 上一页 10 11 12 13 14 15 16 17 18 下一页