少年阿宾

那些青春的岁月

  BlogJava :: 首页 :: 联系 :: 聚合  :: 管理
  500 Posts :: 0 Stories :: 135 Comments :: 0 Trackbacks

#

     摘要: Struts2拦截器(Interceptor)                              &...  阅读全文
posted @ 2012-03-14 23:35 abin 阅读(686) | 评论 (0)编辑 收藏

MYSQL中 ENUM 类型的详细解释

ENUM 类型

ENUM 是一个字符串对象,其值通常选自一个允许值列表中,该列表在表创建时的列规格说明中被明确地列举。

在下列某些情况下,值也可以是空串("") 或 NULL

  • 如果将一个无效值插入一个 ENUM (即,一个不在允许值列表中的字符串),空字符串将作为一个特殊的错误值被插入。事实上,这个字符串有别于一个"普通的"空字符串,因为这个字符串有个数字索引值为 0。稍后有更详细描述。
  • 如果一个 ENUM 被声明为 NULLNULL 也是该列的一个合法值,并且该列的缺省值也将为 NULL 。如果一个 ENUM 被声明为 NOT NULL,该列的缺省值将是该列表所允许值的第一个成员。

每个枚举值均有一个索引值:

  • 在列说明中列表值所允许的成员值被从 1 开始编号。
  • 空字符串错误值的索引值为 0。这就意味着,你可以使用下面所示的 SELECT 语句找出被赋于无效 ENUM 值的记录行。
    mysql> SELECT * FROM tbl_name WHERE enum_col=0;
  • NULL 值的索引值为 NULL

例如,指定为 ENUM("one", "two", "three") 的一个列,可以有下面所显示的任一值。每个值的索引值也如下所示:

索引值
NULL NULL
"" 0
"one" 1
"two" 2
"three" 3

换个枚举最大可以有 65535 个成员值。

从 MySQL 3.23.51 开始,当表被创建时,ENUM 值尾部的空格将会自动删除。

当为一个 ENUM 列赋值时,字母的大小写是无关紧要的。然而,以后从列中检索出来的值的大小写却是匹配于创建表时所指定的允许值。

如果在一个数字语境中检索一个ENUM,列值的索引值将被返回。例如,你可以像这样使用数字值检索一个 ENUM 列:

mysql> SELECT enum_col+0 FROM tbl_name;

如果将一个数字存储到一个 ENUM 中,数字被当作为一个索引值,并且存储的值是该索引值所对应的枚举成员。(但是,这在 LOAD DATA 将不能工作,因为它视所有的输入均为字符串。) 在一个 ENUM 字符串中存储数字是不明智的,因为它可能会打乱思维。

ENUM 值依照列规格说明中的列表顺序进行排序。(换句话说,ENUM 值依照它们的索引号排序。)举例来说,对于 ENUM("a", "b") "a" 排在 "b" 后,但是对于 ENUM("b", "a") "b" 却排在 "a" 之前。空字符串排在非空字符串前,NULL 值排在其它所有的枚举值前。为了防止意想不到的结果,建议依照字母的顺序定义 ENUM 列表。也可以通过使用 GROUP BY CONCAT(col) 来确定该以字母顺序排序而不是以索引值。

如果希望得到一个 ENUM 列的所有可能值,可以使用 SHOW COLUMNS FROM table_name LIKE enum_colum

posted @ 2012-03-12 23:31 abin 阅读(500) | 评论 (0)编辑 收藏

一、MySQL 字段数据类型/长度

1、数值类型

列类型              需要的存储量 
TINYINT                1 字节 
SMALLINT             2 个字节 
MEDIUMINT          3 个字节 
INT                       4 个字节 
INTEGER             4 个字节 
BIGINT                 8 个字节 
FLOAT(X)           4 如果 X < = 24 或 8 如果 25 < = X < = 53 
FLOAT                 4 个字节 
DOUBLE              8 个字节 
DOUBLE PRECISION     8 个字节 
REAL                    8 个字节 
DECIMAL(M,D)   M字节(D+2 , 如果M < D) 
NUMERIC(M,D)   M字节(D+2 , 如果M < D)

MySQL 的数值数据类型可以大致划分为两个类别,一个是整数,另一个是浮点数或小数。许多不同的子类型对这些类别中的每一个都是可用的,每个子类型支持不同大小的数据,并且 MySQL 允许我们指定数值字段中的值是否有正负之分或者用零填补。

  表列出了各种数值类型以及它们的允许范围和占用的内存空间。

类型
大小
范围(有符号)
范围(无符号)
用途
TINYINT
1 字节
(-128,127)
(0,255)
小整数值
SMALLINT
2 字节
(-32 768,32 767)
(0,65 535)
大整数值
MEDIUMINT
3 字节
(-8 388 608,8 388 607)
(0,16 777 215)
大整数值
INT或INTEGER
4 字节
(-2 147 483 648,2 147 483 647)
(0,4 294 967 295)
大整数值
BIGINT
8 字节
(-9 233 372 036 854 775 808,9 223 372 036 854 775 807)
(0,18 446 744 073 709 551 615)
极大整数值
FLOAT
4 字节
(-3.402 823 466 E+38,1.175 494 351 E-38),0,(1.175 494 351 E-38,3.402 823 466 351 E+38)
0,(1.175 494 351 E-38,3.402 823 466 E+38)
单精度
浮点数值
DOUBLE
8 字节
(1.797 693 134 862 315 7 E+308,2.225 073 858 507 201 4 E-308),0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308)
0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308)
双精度
浮点数值
DECIMAL
对DECIMAL(M,D) ,如果M>D,为M+2否则为D+2
依赖于M和D的值
依赖于M和D的值
小数值

INT 类型

  在 MySQL 中支持的 5 个主要整数类型是 TINYINT,SMALLINT,MEDIUMINT,INT 和 BIGINT。这些类型在很大程度上是相同的,只有它们存储的值的大小是不相同的。

  MySQL 以一个可选的显示宽度指示器的形式对 SQL 标准进行扩展,这样当从数据库检索一个值时,可以把这个值加长到指定的长度。例如,指定一个字段的类型为 INT(6),就可以保证所包含数字少于 6 个的值从数据库中检索出来时能够自动地用空格填充。需要注意的是,使用一个宽度指示器不会影响字段的大小和它可以存储的值的范围。

  万一我们需要对一个字段存储一个超出许可范围的数字,MySQL 会根据允许范围最接近它的一端截短后再进行存储。还有一个比较特别的地方是,MySQL 会在不合规定的值插入表前自动修改为 0。

  UNSIGNED(未签署) 修饰符规定字段只保存正值。因为不需要保存数字的正、负符号,可以在储时节约一个“位”的空间。从而增大这个字段可以存储的值的范围。

  ZEROFILL(零填充) 修饰符规定 0(不是空格)可以用来真补输出的值。使用这个修饰符可以阻止 MySQL 数据库存储负值。

FLOAT、DOUBLE 和 DECIMAL 类型

  MySQL 支持的三个浮点类型是 FLOAT、DOUBLE 和 DECIMAL 类型。FLOAT 数值类型用于表示单精度浮点数值,而 DOUBLE 数值类型用于表示双精度浮点数值。

  与整数一样,这些类型也带有附加参数:一个显示宽度指示器和一个小数点指示器。比如语句 FLOAT(7,3) 规定显示的值不会超过 7 位数字,小数点后面带有 3 位数字。

  对于小数点后面的位数超过允许范围的值,MySQL 会自动将它四舍五入为最接近它的值,再插入它。

  DECIMAL 数据类型用于精度要求非常高的计算中,这种类型允许指定数值的精度和计数方法作为选择参数。精度在这里指为这个值保存的有效数字的总个数,而计数方法表示小数点后数字的位数。比如语句 DECIMAL(7,3) 规定了存储的值不会超过 7 位数字,并且小数点后不超过 3 位。

  忽略 DECIMAL 数据类型的精度和计数方法修饰符将会使 MySQL 数据库把所有标识为这个数据类型的字段精度设置为 10,计算方法设置为 0。

  UNSIGNED(未签署) 和 ZEROFILL(零填充) 修饰符也可以被 FLOAT、DOUBLE 和 DECIMAL 数据类型使用。并且效果与 INT 数据类型相同。

2、日期和时间类型

列类型                  需要的存储量 
DATE                        3 个字节 
DATETIME                8 个字节 
TIMESTAMP             4 个字节 
TIME                         3 个字节 
YEAR                        1 字节

      在处理日期和时间类型的值时,MySQL 带有 5 个不同的数据类型可供选择。它们可以被分成简单的日期、时间类型,和混合日期、时间类型。根据要求的精度,子类型在每个分类型中都可以使用,并且 MySQL 带有内置功能可以把多样化的输入格式变为一个标准格式

类型
大小
(字节)
范围
格式
用途
DATE
3
1000-01-01/9999-12-31
YYYY-MM-DD
日期值
TIME
3
'-838:59:59'/'838:59:59'
HH:MM:SS
时间值或持续时间
YEAR
1
1901/2155
YYYY
年份值
DATETIME
8
1000-01-01 00:00:00/9999-12-31 23:59:59
YYYY-MM-DD HH:MM:SS
混合日期和时间值
TIMESTAMP
8
1970-01-01 00:00:00/2037 年某时
YYYYMMDD HHMMSS
混合日期和时间值,时间戳

DATE、TIME 和 TEAR 类型

  MySQL 用 DATE 和 TEAR 类型存储简单的日期值,使用 TIME 类型存储时间值。这些类型可以描述为字符串或不带分隔符的整数序列。如果描述为字符串,DATE 类型的值应该使用连字号作为分隔符分开,而 TIME 类型的值应该使用冒号作为分隔符分开。

  需要注意的是,没有冒号分隔符的 TIME 类型值,将会被 MySQL 理解为持续的时间,而不是时间戳。

  MySQL 还对日期的年份中的两个数字的值,或是 SQL 语句中为 TEAR 类型输入的两个数字进行最大限度的通译。因为所有 TEAR 类型的值必须用 4 个数字存储。MySQL 试图将 2 个数字的年份转换为 4 个数字的值。把在 00-69 范围内的值转换到 2000-2069 范围内。把 70-99 范围内的值转换到 1970-1979 之内。如果 MySQL 自动转换后的值并不符合我们的需要,请输入 4 个数字表示的年份。

DATETIME 和 TIMESTAMP 类型

   除了日期和时间数据类型,MySQL 还支持 DATEYIME 和 TIMESTAMP 这两种混合类型。它们可以把日期和时间作为单个的值进行存储。这两种类型通常用于自动存储包含当前日期和时间的时间戳,并可在需要执行大量数据库事务和需要建立一个调试和审查用途的审计跟踪的应用程序中发挥良好作用。

  如果我们对 TIMESTAMP 类型的字段没有明确赋值,或是被赋与了 null 值。MySQL 会自动使用系统当前的日期和时间来填充它。

3、字符串类型

列类型                            需要的存储量 
CHAR(M)                         M字节,1 <= M <= 255 
VARCHAR(M)                  L+1 字节, 在此L <= M和1 <= M <= 255 
TINYBLOB, TINYTEXT     L+1 字节, 在此L< 2 ^ 8 
BLOB, TEXT                   L+2 字节, 在此L< 2 ^ 16 
MEDIUMBLOB, MEDIUMTEXT            L+3 字节, 在此L< 2 ^ 24 
LONGBLOB, LONGTEXT                   L+4 字节, 在此L< 2 ^ 32 
ENUM('value1','value2',...)               1 或 2 个字节, 取决于枚举值的数目(最大值65535) 
SET('value1','value2',...)                  1,2,3,4或8个字节, 取决于集合成员的数量(最多64个成员)

      MySQL 提供了 8 个基本的字符串类型,可以存储的范围从简单的一个字符到巨大的文本块或二进制字符串数据。

类型
大小
用途
CHAR
0-255字节
定长字符串
VARCHAR
0-255字节
变长字符串
TINYBLOB
0-255字节
不超过 255 个字符的二进制字符串
TINYTEXT
0-255字节
短文本字符串
BLOB
0-65 535字节
二进制形式的长文本数据
TEXT
0-65 535字节
长文本数据
MEDIUMBLOB
0-16 777 215字节
二进制形式的中等长度文本数据
MEDIUMTEXT
0-16 777 215字节
中等长度文本数据
LOGNGBLOB
0-4 294 967 295字节
二进制形式的极大文本数据
LONGTEXT
0-4 294 967 295字节
极大文本数据

CHAR 和 VARCHAR 类型

  CHAR 类型用于定长字符串,并且必须在圆括号内用一个大小修饰符来定义。这个大小修饰符的范围从 0-255。比指定长度大的值将被截短,而比指定长度小的值将会用空格作填补。

  CHAR 类型可以使用 BINARY 修饰符。当用于比较运算时,这个修饰符使 CHAR 以二进制方式参于运算,而不是以传统的区分大小写的方式。

  CHAR 类型的一个变体是 VARCHAR 类型。它是一种可变长度的字符串类型,并且也必须带有一个范围在 0-255 之间的指示器。CHAR 和 VARCHGAR 不同之处在于 MuSQL 数据库处理这个指示器的方式:CHAR 把这个大小视为值的大小,不长度不足的情况下就用空格补足。而 VARCHAR 类型把它视为最大值并且只使用存储字符串实际需要的长度(增加一个额外字节来存储字符串本身的长度)来存储值。所以短于指示器长度的 VARCHAR 类型不会被空格填补,但长于指示器的值仍然会被截短。

  因为 VARCHAR 类型可以根据实际内容动态改变存储值的长度,所以在不能确定字段需要多少字符时使用 VARCHAR 类型可以大大地节约磁盘空间、提高存储效率。

  VARCHAR 类型在使用 BINARY 修饰符时与 CHAR 类型完全相同。

TEXT 和 BLOB 类型

  对于字段长度要求超过 255 个的情况下,MySQL 提供了 TEXT 和 BLOB 两种类型。根据存储数据的大小,它们都有不同的子类型。这些大型的数据用于存储文本块或图像、声音文件等二进制数据类型。

  TEXT 和 BLOB 类型在分类和比较上存在区别。BLOB 类型区分大小写,而 TEXT 不区分大小写。大小修饰符不用于各种 BLOB 和 TEXT 子类型。比指定类型支持的最大范围大的值将被自动截短。

3、复合类型

  MySQL 还支持两种复合数据类型 ENUM 和 SET,它们扩展了 SQL 规范。虽然这些类型在技术上是字符串类型,但是可以被视为不同的数据类型。一个 ENUM 类型只允许从一个集合中取得一个值;而 SET 类型允许从一个集合中取得任意多个值。

ENUM 类型

  ENUM 类型因为只允许在集合中取得一个值,有点类似于单选项。在处理相互排拆的数据时容易让人理解,比如人类的性别。ENUM 类型字段可以从集合中取得一个值或使用 null 值,除此之外的输入将会使 MySQL 在这个字段中插入一个空字符串。另外如果插入值的大小写与集合中值的大小写不匹配,MySQL 会自动使用插入值的大小写转换成与集合中大小写一致的值。

   ENUM 类型在系统内部可以存储为数字,并且从 1 开始用数字做索引。一个 ENUM 类型最多可以包含 65536 个元素,其中一个元素被 MySQL 保留,用来存储错误信息,这个错误值用索引 0 或者一个空字符串表示。

  MySQL 认为 ENUM 类型集合中出现的值是合法输入,除此之外其它任何输入都将失败。这说明通过搜索包含空字符串或对应数字索引为 0 的行就可以很容易地找到错误记录的位置。

SET 类型

  SET 类型与 ENUM 类型相似但不相同。SET 类型可以从预定义的集合中取得任意数量的值。并且与 ENUM 类型相同的是任何试图在 SET 类型字段中插入非预定义的值都会使 MySQL 插入一个空字符串。如果插入一个即有合法的元素又有非法的元素的记录,MySQL 将会保留合法的元素,除去非法的元素。

  一个 SET 类型最多可以包含 64 项元素。在 SET 元素中值被存储为一个分离的“位”序列,这些“位”表示与它相对应的元素。“位”是创建有序元素集合的一种简单而有效的方式。并且它还去除了重复的元素,所以 SET 类型中不可能包含两个相同的元素。

  希望从 SET 类型字段中找出非法的记录只需查找包含空字符串或二进制值为 0 的行。

二、MySQL 数据表类型说明

1. MyISAM 表 MyISAM 存储格式自版本3.23 以来是 MySQL 中的缺省类型,它有下列特点:
■ 如果操作系统自身允许更大的文件,那么文件比 ISAM 存储方法的大。
■ 数据以低字节优先的机器独立格式存储。这表示可将表从一种机器拷贝到另一种机器,即使它们的体系结构不同也可以拷贝。
■ 数值索引值占的存储空间较少,因为它们是按高字节优先存储的。索引值在低位字节中变化很快,因此高位字节更容易比较。
■ AUTO_INCREMENT 处理比 ISAM 的表更好。
■ 减少了几个索引限制。例如,可对含 NULL 值的列进行索引,还可以对 BLOB 和 TEXT 类型的列进行索引。
■ 为了改善表的完整性检查,每个表都具有一个标志,在 myisamchk 对表进行过检查后,设置该标志。可利用 myisamchk - fast 跳过对自前次检查以来尚未被修改过表的检查,这样使此管理任务更快。表中还有一个指示表是否正常关闭的标志。如果服务器关闭不正常,或机器崩溃,此标志可用来检测出服务器起动时需要检查的表。

2. ISAM 表 ISAM 存储格式是 MySQL3.23 所用的最旧的格式,但当前仍然可用。通常,相对于 ISAM 表来说,宁可使用 MyISAM 表,因为它们的限制较少。对 ISAM 表的支持随着此存储格式被 MyISAM 表格式所支持很有可能会逐渐消失。

3. HEAP 表 HEAP 存储格式建立利用定长行的内存中的表,这使表运行得非常快。在服务器停止时,它们将会消失。在这种意义上,这些表是临时的。但是,与用 CREATE TEMPORARY TABLE 所创建的临时表相比,HEAP 表是其他客户机可见的。HEAP 表有几个限制,这些限制对 MyISAM 或 ISAM 表没有,如下所示:
■ 索引仅用于“=”和“< = >”比较。
■ 索引列中不能有 NULL 值。
■ 不能使用 BLOB 和 TEXT 列。
■ 不能使用 AUTO_INCREMENT 列。 

posted @ 2012-03-12 22:58 abin 阅读(1744) | 评论 (0)编辑 收藏

package com.abin.inter.service;

public interface UserService {
 
 public static enum UserType{
  UserBasic("Basic Information"),
  UserName("Name Of User"),
  UserSex("Sex Of User"),
  UserAge("Age Of User"),
  UserInitialize("Initialize Of User");
  
  private String info;
  private UserType(String _info){
   this.info=_info;
  }
  
  public String getObject(){
   return info;
  }
 };
 
 
 int UserSum(int one,int two,UserType userInfo);
 String Welcome(String username,UserType userInfo);
}







package com.abin.inter.serviceImpl;

import com.abin.inter.service.UserService;

public class UserServiceImpl implements UserService{
 @Override
 public int UserSum(int one, int two,UserType userInfo) {
  UserType user=UserType.UserInitialize;
  System.out.println("Enum Info:"+user.getObject());
  if(userInfo.equals(UserType.UserAge)){
   System.out.println("UserInfo:"+userInfo);
   return one+two;
  }
  return 0;
 }

 @Override
 public String Welcome(String username,UserType userInfo) {
  UserType user=UserType.UserInitialize;
  System.out.println("Enum Info:"+user);
  if(userInfo.equals(UserType.UserName)){
   System.out.println("UserInfo:"+userInfo);
   return "欢迎"+username;
  }
  return "NOT WELCOME";
 }

 @Override
 public String toString() {
  // TODO Auto-generated method stub
  return super.toString();
 }
 
 
}








package com.abin.inter.test;

import com.abin.inter.service.UserService;
import com.abin.inter.service.UserService.UserType;
import com.abin.inter.serviceImpl.UserServiceImpl;

import junit.framework.TestCase;

public class TestUser extends TestCase{
 
 public void test(){
  UserService service=new UserServiceImpl();
  UserType userInfo=UserType.UserAge;
  int result=service.UserSum(10, 17, userInfo);
  System.out.println("UserSum="+result);
  UserType userInfo1=UserType.UserName;
  String result1=service.Welcome("abin", userInfo1);
  System.out.println("Welcome="+result1);
  
 }
}





运行结果:
Enum Info:Initialize Of User
UserInfo:UserAge
UserSum=27
Enum Info:UserInitialize
UserInfo:UserName
Welcome=欢迎abin
posted @ 2012-03-12 22:29 abin 阅读(636) | 评论 (0)编辑 收藏

   缓存是介于应用程序和物理数据源之间,其作用是为了降低应用程序对物理数据源访问的频次,从而提高了应用的运行性能。缓存内的数据是对物理数据源中的数据的复制,应用程序在运行时从缓存读写数据,在特定的时刻或事件会同步缓存和物理数据源的数据。

  缓存的介质一般是内存,所以读写速度很快。但如果缓存中存放的数据量非常大时,也会用硬盘作为缓存介质。缓存的实现不仅仅要考虑存储的介质,还要考虑到管理缓存的并发访问和缓存数据的生命周期。

  Hibernate的缓存包括Session的缓存和SessionFactory的缓存,其中SessionFactory的缓存又可以分为两类:内置缓存和外置缓存。Session的缓存是内置的,不能被卸载,也被称为Hibernate的第一级缓存。SessionFactory的内置缓存和Session的缓存在实现方式上比较相似,前者是SessionFactory对象的一些集合属性包含的数据,后者是指Session的一些集合属性包含的数据。SessionFactory的内置缓存中存放了映射元数据和预定义SQL语句,映射元数据是映射文件中数据的拷贝,而预定义SQL语句是在Hibernate初始化阶段根据映射元数据推导出来,SessionFactory的内置缓存是只读的,应用程序不能修改缓存中的映射元数据和预定义SQL语句,因此SessionFactory不需要进行内置缓存与映射文件的同步。SessionFactory的外置缓存是一个可配置的插件。在默认情况下,SessionFactory不会启用这个插件。外置缓存的数据是数据库数据的拷贝,外置缓存的介质可以是内存或者硬盘。SessionFactory的外置缓存也被称为Hibernate的第二级缓存。

  Hibernate的这两级缓存都位于持久化层,存放的都是数据库数据的拷贝,那么它们之间的区别是什么呢?为了理解二者的区别,需要深入理解持久化层的缓存的两个特性:缓存的范围和缓存的并发访问策略。

  持久化层的缓存的范围

  缓存的范围决定了缓存的生命周期以及可以被谁访问。缓存的范围分为三类。

  1 事务范围:缓存只能被当前事务访问。缓存的生命周期依赖于事务的生命周期,当事务结束时,缓存也就结束生命周期。在此范围下,缓存的介质是内存。事务可以是数据库事务或者应用事务,每个事务都有独自的缓存,缓存内的数据通常采用相互关联的的对象形式。

  2 进程范围:缓存被进程内的所有事务共享。这些事务有可能是并发访问缓存,因此必须对缓存采取必要的事务隔离机制。缓存的生命周期依赖于进程的生命周期,进程结束时,缓存也就结束了生命周期。进程范围的缓存可能会存放大量的数据,所以存放的介质可以是内存或硬盘。缓存内的数据既可以是相互关联的对象形式也可以是对象的松散数据形式。松散的对象数据形式有点类似于对象的序列化数据,但是对象分解为松散的算法比对象序列化的算法要求更快。

  3 集群范围:在集群环境中,缓存被一个机器或者多个机器的进程共享。缓存中的数据被复制到集群环境中的每个进程节点,进程间通过远程通信来保证缓存中的数据的一致性,缓存中的数据通常采用对象的松散数据形式。

  对大多数应用来说,应该慎重地考虑是否需要使用集群范围的缓存,因为访问的速度不一定会比直接访问数据库数据的速度快多少。

  持久化层可以提供多种范围的缓存。如果在事务范围的缓存中没有查到相应的数据,还可以到进程范围或集群范围的缓存内查询,如果还是没有查到,那么只有到数据库中查询。事务范围的缓存是持久化层的第一级缓存,通常它是必需的;进程范围或集群范围的缓存是持久化层的第二级缓存,通常是可选的。

  持久化层的缓存的并发访问策略

  当多个并发的事务同时访问持久化层的缓存的相同数据时,会引起并发问题,必须采用必要的事务隔离措施。

  在进程范围或集群范围的缓存,即第二级缓存,会出现并发问题。因此可以设定以下四种类型的并发访问策略,每一种策略对应一种事务隔离级别。

  事务型:仅仅在受管理环境中适用。它提供了Repeatable Read事务隔离级别。对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读和不可重复读这类的并发问题。

  读写型:提供了Read Committed事务隔离级别。仅仅在非集群的环境中适用。对于经常被读但很少修改的数据,可以采用这种隔离类型,因为它可以防止脏读这类的并发问题。

  非严格读写型:不保证缓存与数据库中数据的一致性。如果存在两个事务同时访问缓存中相同数据的可能,必须为该数据配置一个很短的数据过期时间,从而尽量避免脏读。对于极少被修改,并且允许偶尔脏读的数据,可以采用这种并发访问策略。   只读型:对于从来不会修改的数据,如参考数据,可以使用这种并发访问策略。

  事务型并发访问策略是事务隔离级别最高,只读型的隔离级别最低。事务隔离级别越高,并发性能就越低。

  什么样的数据适合存放到第二级缓存中?

  1、很少被修改的数据

  2、不是很重要的数据,允许出现偶尔并发的数据

  3、不会被并发访问的数据

  4、参考数据

  不适合存放到第二级缓存的数据?

  1、经常被修改的数据

  2、财务数据,绝对不允许出现并发

  3、与其他应用共享的数据。

  Hibernate的二级缓存

  如前所述,Hibernate提供了两级缓存,第一级是Session的缓存。由于Session对象的生命周期通常对应一个数据库事务或者一个应用事务,因此它的缓存是事务范围的缓存。第一级缓存是必需的,不允许而且事实上也无法比卸除。在第一级缓存中,持久化类的每个实例都具有唯一的OID。

  第二级缓存是一个可插拔的的缓存插件,它是由SessionFactory负责管理。由于SessionFactory对象的生命周期和应用程序的整个过程对应,因此第二级缓存是进程范围或者集群范围的缓存。这个缓存中存放的对象的松散数据。第二级对象有可能出现并发问题,因此需要采用适当的并发访问策略,该策略为被缓存的数据提供了事务隔离级别。缓存适配器用于把具体的缓存实现软件与Hibernate集成。第二级缓存是可选的,可以在每个类或每个集合的粒度上配置第二级缓存。

  Hibernate的二级缓存策略的一般过程如下:

  1) 条件查询的时候,总是发出一条select * from table_name where …. (选择所有字段)这样的SQL语句查询数据库,一次获得所有的数据对象。

  2) 把获得的所有数据对象根据ID放入到第二级缓存中。

  3) 当Hibernate根据ID访问数据对象的时候,首先从Session一级缓存中查;查不到,如果配置了二级缓存,那么从二级缓存中查;查不到,再查询数据库,把结果按照ID放入到缓存。

  4) 删除、更新、增加数据的时候,同时更新缓存。

  Hibernate的二级缓存策略,是针对于ID查询的缓存策略,对于条件查询则毫无作用。为此,Hibernate提供了针对条件查询的Query缓存。

  Hibernate的Query缓存策略的过程如下:

  1) Hibernate首先根据这些信息组成一个Query Key,Query Key包括条件查询的请求一般信息:SQL, SQL需要的参数,记录范围(起始位置rowStart,最大记录个数maxRows),等。

  2) Hibernate根据这个Query Key到Query缓存中查找对应的结果列表。如果存在,那么返回这个结果列表;如果不存在,查询数据库,获取结果列表,把整个结果列表根据Query Key放入到Query缓存中。

  3) Query Key中的SQL涉及到一些表名,如果这些表的任何数据发生修改、删除、增加等操作,这些相关的Query Key都要从缓存中清空。

posted @ 2012-03-11 22:25 abin 阅读(488) | 评论 (0)编辑 收藏

来源:http://www.tianxiaboke.com/u/lyeerwy

级联保存和更新
当Hibernate持久化一个临时对象时,在默认情下,他不会自动持久化所关联的其他临时对象,如果希望当持久化对象时把他所关联的所有临时对象进行持久化的话:可以把 的cascade属性设置为"save-update" ,cascade的默认属性值为none。
cascade:设置操作对象时的级联操作,即层级之间的连锁操作
值 save-update :表示当保存和更新当前对象(即insert和update语句时),会级联保存和更新与他关联的对象
值 all :表示任何情况下都会进行级联操作,即对一个对象进行操作,也会对和他关联的其他对象进行同样的操作
值 delete :表示在执行delete时,进行级联操作,删除和他关联的对象
值 none :表示任何情况下,都不会进行级联操作
<set>元素的inverse属性

在运行上面的程序时,如果hibernate的"show-sql"设置为true时,就会看到Hibernate会生成很多sql语句,其实很多sql语句都是重复的
eg: 
insert into  test.order(o_name,c_id)values(?,?)
insert into  test.order(o_name,c_id)values(?,?)
insert into  test order   set c_id=? where id=?
insert into  test order   set c_id=? where id=?

为了解决这个问题,我们可以利用在<set>标签中加上inverse属性。术语:inverse是指反转的意思,在 Hibernate中,表示关联关系中的方向关联关系中,inverse="false"的主控方,由主动方负责维护对象关系我们 在customer对象的对象配置文件中加上

<set name="orders"  cascade="save-update" inverse="true">
<key  column="c_id" > </key>
<one-to-many class="net.mbs.mypack.Order " />
</set>

声明在Customer和Order的双向关联关系中,Customer端的关联只是Order端关联的镜象(即Order端是主空端,负责维护 Customer和order对象之间的关联关系),当hibernate探测到持久化对象Customer或Order的状态发生变化时(主要是关联关系的改变),仅按照Order对象的状态的变化来同步更新数据库。
按次配置,如果在程序中,我们仅仅使用Customer.getOrder().add(order)(涉及了和Order的关联关系的改变),是不能让数据库跟对象的变化来进行数据库同步更新的,只有利用Order对象的方法改变的Order对象状态 (eg:order.setCustomer(customer)----涉及到了和Customer的关联关系的改变)时,数据库才会根据变化来同步更新数据库,即只有主控方的状态(涉及到了和另一方面的关联关系的改变)发生了变化后,才会触发对象和数据库的同步更新。

映射一对多双向关联关系
当类与类之间建立了关联,就可以方便的从一个对象导航到另一个对象或一组与他关联的对象当中,根据上面的程序,对于一个给定的Order对象,如果想获取与他关联的Customer对象,我们只需要调用入下方法:
Customer c=order.geCustomer(); 那么当我们得到一个Customer对象后,想查出和这个Customer对象关联的所有Order对象时,应该怎么办呢?由于在Customer中没有建立对Order对象的关联,所以,不能通过加载Customer对象来自动加载和他关联的所有Order对象,唯一的方法只能通过JDBC或SQL语言人工写出代码来查询数据库Order表来返回所需要的信息
上面的问题虽然解决,但不能算是最好,因为这样性能会有所下降,对象位于内存中,在内存中从一个对象导航到另一个对象显然比到数据库中查询数据要快得多

具体实现<br>
1:由于Customer和Order是一对多,即一个Customer要对应多个Order,所以在Customer中应该建立一个Set对象,用于存放和本Customer对象关联的所有Order对象。
2:在customer.hbm.xml通过<one-to-many>建立对Order表的关联关系
注意:<one-to-many>应该放置在<set>标签中 
我们先来看看Customer类的设计和customer.hbm.xml文件的内容
<br><br><br>------------------------------------------------------
Customer Order 双向一对多
1:Customer类中建立一个容器对象,包含关联的所有Order对象
2:Order类中建立一个Customer对象,关联Customer
inverse="true"表示将维护关联的权利交给引起Hibernate语句的生成

customer.getOrders().add(order);
customer.setName("dddddd");

inverse="true"(设置此属性的一方----是被控方)
当主控方修改对象之间的关联关系时,让Hibernate生成sql语句

posted @ 2012-03-11 16:36 abin 阅读(1122) | 评论 (0)编辑 收藏

  5个最常问的几个Hibernate面试问题,不一定你都能回答:

1.实体对象在Hibernate中如何进行状态迁移?
2.何谓Hibernate的N+1问题,如何解决?
3.Hibernate延迟加载的机制是什么,如何工作?
4.Hibernate级联保存要如何做?
5.Hibernate的二级缓存和一级缓存有什么区别?
posted @ 2012-03-11 15:34 abin 阅读(596) | 评论 (0)编辑 收藏

延迟加载:

   延迟加载机制是为了避免一些无谓的性能开销而提出来的,所谓延迟加载就是当在真正需要数据的时候,才真正执行数据加载操作。在Hibernate中提供了对实体对象的延迟加载以及对集合的延迟加载,另外在Hibernate3中还提供了对属性的延迟加载。下面我们就分别介绍这些种类的延迟加载的细节。

A、实体对象的延迟加载:

如果想对实体对象使用延迟加载,必须要在实体的映射配置文件中进行相应的配置,如下所示:

<hibernate-mapping>

<class name=”com.neusoft.entity.User” table=”user” lazy=”true”>

    ……

</class>

</hibernate-mapping>

通过将class的lazy属性设置为true,来开启实体的延迟加载特性。如果我们运行下面的代码:

User user=(User)session.load(User.class,”1”);(1)

System.out.println(user.getName());(2)

当运行到(1)处时,Hibernate并没有发起对数据的查询,如果我们此时通过一些调试工具(比如JBuilder2005的Debug工具),观察此时user对象的内存快照,我们会惊奇的发现,此时返回的可能是User$EnhancerByCGLIB$$bede8986类型的对象,而且其属性为 null,这是怎么回事?还记得前面我曾讲过session.load()方法,会返回实体对象的代理类对象,这里所返回的对象类型就是User对象的代理类对象。在Hibernate中通过使用CGLIB,来实现动态构造一个目标对象的代理类对象,并且在代理类对象中包含目标对象的所有属性和方法,而且所有属性均被赋值为null。通过调试器显示的内存快照,我们可以看出此时真正的User对象,是包含在代理对象的 CGLIB$CALBACK_0.target属性中,当代码运行到(2)处时,此时调用user.getName()方法,这时通过CGLIB赋予的回调机制,实际上调用CGLIB$CALBACK_0.getName()方法,当调用该方法时,Hibernate会首先检查 CGLIB$CALBACK_0.target属性是否为null,如果不为空,则调用目标对象的getName方法,如果为空,则会发起数据库查询,生成类似这样的SQL语句:select * from user where id=’1’;来查询数据,并构造目标对象,并且将它赋值到CGLIB$CALBACK_0.target属性中。

    这样,通过一个中间代理对象,Hibernate实现了实体的延迟加载,只有当用户真正发起获得实体对象属性的动作时,才真正会发起数据库查询操作。所以实体的延迟加载是用通过中间代理类完成的,所以只有session.load()方法才会利用实体延迟加载,因为只有session.load()方法才会返回实体类的代理类对象。

B、        集合类型的延迟加载:

在Hibernate的延迟加载机制中,针对集合类型的应用,意义是最为重大的,因为这有可能使性能得到大幅度的提高,为此Hibernate进行了大量的努力,其中包括对JDK Collection的独立实现,我们在一对多关联中,定义的用来容纳关联对象的Set集合,并不是java.util.Set类型或其子类型,而是 net.sf.hibernate.collection.Set类型,通过使用自定义集合类的实现,Hibernate实现了集合类型的延迟加载。为了对集合类型使用延迟加载,我们必须如下配置我们的实体类的关于关联的部分:

<hibernate-mapping>

    <class name=”com.neusoft.entity.User” table=”user”>

…..

<set name=”addresses” table=”address” lazy=”true” inverse=”true”>

<key column=”user_id”/>

<one-to-many class=”com.neusoft.entity.Arrderss”/>

</set>

    </class>

</hibernate-mapping>

通过将<set>元素的lazy属性设置为true来开启集合类型的延迟加载特性。我们看下面的代码:

User user=(User)session.load(User.class,”1”);

Collection addset=user.getAddresses();       (1)

Iterator it=addset.iterator();                (2)

while(it.hasNext()){

Address address=(Address)it.next();

System.out.println(address.getAddress());

}

当程序执行到(1)处时,这时并不会发起对关联数据的查询来加载关联数据,只有运行到(2)处时,真正的数据读取操作才会开始,这时Hibernate会根据缓存中符合条件的数据索引,来查找符合条件的实体对象。

这里我们引入了一个全新的概念——数据索引,下面我们首先将接一下什么是数据索引。在Hibernate中对集合类型进行缓存时,是分两部分进行缓存的,首先缓存集合中所有实体的id列表,然后缓存实体对象,这些实体对象的id列表,就是所谓的数据索引。当查找数据索引时,如果没有找到对应的数据索引,这时就会一条select SQL的执行,获得符合条件的数据,并构造实体对象集合和数据索引,然后返回实体对象的集合,并且将实体对象和数据索引纳入Hibernate的缓存之中。另一方面,如果找到对应的数据索引,则从数据索引中取出id列表,然后根据id在缓存中查找对应的实体,如果找到就从缓存中返回,如果没有找到,在发起select SQL查询。在这里我们看出了另外一个问题,这个问题可能会对性能产生影响,这就是集合类型的缓存策略。如果我们如下配置集合类型:

<hibernate-mapping>

    <class name=”com.neusoft.entity.User” table=”user”>

…..

<set name=”addresses” table=”address” lazy=”true” inverse=”true”>

<cache usage=”read-only”/>

<key column=”user_id”/>

<one-to-many class=”com.neusoft.entity.Arrderss”/>

</set>

    </class>

</hibernate-mapping>

这里我们应用了<cache usage=”read-only”/>配置,如果采用这种策略来配置集合类型,Hibernate将只会对数据索引进行缓存,而不会对集合中的实体对象进行缓存。如上配置我们运行下面的代码:

User user=(User)session.load(User.class,”1”);

Collection addset=user.getAddresses();      

Iterator it=addset.iterator();               

while(it.hasNext()){

Address address=(Address)it.next();

System.out.println(address.getAddress());

}

System.out.println(“Second query……”);

User user2=(User)session.load(User.class,”1”);

Collection it2=user2.getAddresses();

while(it2.hasNext()){

Address address2=(Address)it2.next();

System.out.println(address2.getAddress());

}

运行这段代码,会得到类似下面的输出:

Select * from user where id=’1’;

Select * from address where user_id=’1’;

Tianjin

Dalian

Second query……

Select * from address where id=’1’;

Select * from address where id=’2’;

Tianjin

Dalian

我们看到,当第二次执行查询时,执行了两条对address表的查询操作,为什么会这样?这是因为当第一次加载实体后,根据集合类型缓存策略的配置,只对集合数据索引进行了缓存,而并没有对集合中的实体对象进行缓存,所以在第二次再次加载实体时,Hibernate找到了对应实体的数据索引,但是根据数据索引,却无法在缓存中找到对应的实体,所以Hibernate根据找到的数据索引发起了两条select SQL的查询操作,这里造成了对性能的浪费,怎样才能避免这种情况呢?我们必须对集合类型中的实体也指定缓存策略,所以我们要如下对集合类型进行配置:

<hibernate-mapping>

    <class name=”com.neusoft.entity.User” table=”user”>

…..

<set name=”addresses” table=”address” lazy=”true” inverse=”true”>

<cache usage=”read-write”/>

<key column=”user_id”/>

<one-to-many class=”com.neusoft.entity.Arrderss”/>

</set>

    </class>

</hibernate-mapping>

此时Hibernate会对集合类型中的实体也进行缓存,如果根据这个配置再次运行上面的代码,将会得到类似如下的输出:

Select * from user where id=’1’;

Select * from address where user_id=’1’;

Tianjin

Dalian

Second query……

Tianjin

Dalian

这时将不会再有根据数据索引进行查询的SQL语句,因为此时可以直接从缓存中获得集合类型中存放的实体对象。

C、       属性延迟加载:

   在Hibernate3中,引入了一种新的特性——属性的延迟加载,这个机制又为获取高性能查询提供了有力的工具。在前面我们讲大数据对象读取时,在 User对象中有一个resume字段,该字段是一个java.sql.Clob类型,包含了用户的简历信息,当我们加载该对象时,我们不得不每一次都要加载这个字段,而不论我们是否真的需要它,而且这种大数据对象的读取本身会带来很大的性能开销。在Hibernate2中,我们只有通过我们前面讲过的面性能的粒度细分,来分解User类,来解决这个问题(请参照那一节的论述),但是在Hibernate3中,我们可以通过属性延迟加载机制,来使我们获得只有当我们真正需要操作这个字段时,才去读取这个字段数据的能力,为此我们必须如下配置我们的实体类:

<hibernate-mapping>

<class name=”com.neusoft.entity.User” table=”user”>

……

<property name=”resume” type=”java.sql.Clob” column=”resume” lazy=”true”/>

    </class>

</hibernate-mapping>

通过对<property>元素的lazy属性设置true来开启属性的延迟加载,在Hibernate3中为了实现属性的延迟加载,使用了类增强器来对实体类的Class文件进行强化处理,通过增强器的增强,将CGLIB的回调机制逻辑,加入实体类,这里我们可以看出属性的延迟加载,还是通过 CGLIB来实现的。CGLIB是Apache的一个开源工程,这个类库可以操纵java类的字节码,根据字节码来动态构造符合要求的类对象。根据上面的配置我们运行下面的代码:

String sql=”from User user where user.name=’zx’ ”;

Query query=session.createQuery(sql);    (1)

List list=query.list();

for(int i=0;i<list.size();i++){

User user=(User)list.get(i);

System.out.println(user.getName());

System.out.println(user.getResume());    (2)

}

当执行到(1)处时,会生成类似如下的SQL语句:

Select id,age,name from user where name=’zx’;

这时Hibernate会检索User实体中所有非延迟加载属性对应的字段数据,当执行到(2)处时,会生成类似如下的SQL语句:

Select resume from user where id=’1’;

这时会发起对resume字段数据真正的读取操作。

posted @ 2012-03-11 15:32 abin 阅读(406) | 评论 (0)编辑 收藏

让Spring架构减化事务配置
注:原创文章,本文曾发表于it168
Spring颠覆了以前的编程模式,引入了IOC等全新的概念,广受大家的喜爱。目前大多数j2ee项目都已经采用Spring框架。Spring最大的问题是太多的配置文件,使得你不仅需要维护程序代码,还需要额外去维护相关的配置文件。最典型的就是事务配置(注:这里的“事务配置”都指“声明式事务配置”),在Spring中进行事务配置除了定义对象自身的bean外,还需要定义一个进行事务代理的bean.如果你有n个类需要引入事务,那么你就必须定义2n个bean。维护这些bean的代价是十分昂贵的,所以必须要对事务配置进行减化。如果你是基于Spring进行架构设计,那么作为一个好的架构设计师,应该把一些公共的方面进行简化,让项目的开发人员只关心项目的业务逻辑,而不要花费太多的精力去关心业务逻辑之外的太多东西。所以作为一个好的架构就应该把事务管理进行简化,让程序员花在编程之外的工作最小化。
1. Spring声明式事务配置的几种方法
在Spring中进行事务控制首先要选择适当的事务管理器,其次为程序选择划分事务的策略。如果只有单个事务性资源,可以从“单一资源”的PlatformTransactionManger实现当中选择一个,这些实现有:DataSourceTransactionManager,HibernateTransactionManager, JdoTransactionManager,PersistenceBrokerTransactionManager和JmsTransactionManager。根据你所采用的数据库持久化技术选择。如果你的项目运行于支持JTA的服务器,那么将选择JtaTransactionManger,将会支持多资源事务。
下表将为你选择适当的事务管理器提供参考。
技术 事务管理器 内建的事务支持
JDBC DataSurceTransactionManagerJtaTransactionManager JdbcTemplate和org.springframework.jdbc.object包中的所有类
IBATIS DataSourceTransactionManagerJtaTransactionManager SqlMapClientTemplate和SqlClientTemplate
Hibernate HibernateTransactionManagerJtaTransactionManager HibernateTemplate和HibernateInterceptor
JDO JdoTransactionManagerJtaTransactionManager JdoTemplate和JdoInterceptor
ApacheOJB PersistenceBrokerTransactionManagerJtaTransactionManager PersistenceBrokerTemplate
JMS JmsTransactionManager JmsTemplate

在划分事务时,我们需要进行事务定义,也就是配置事务的属性。事务的属性有传播行业,隔离级别,超时值及只读标志。TransactionAttribute接口指定哪些异常将导致一个回滚,哪些应该一次性提交。

(1) 使用ProxyFactoryBean 和TransactionInterceptor

<!--定义本地数据源-->

<bean id="dataSource" name="dataSource" class="org.apache.commons.dbcp.BasicDataSource"           destroy-method="close">
<property name="driverClassName" value="${jdbc.driverClassName}"/>
<property name="url" value="${jdbc.url}"/>
<property name="username" value="${jdbc.username}"/>
<property name="password" value="${jdbc.password}"/>
</bean>


<!-- !定义单个jdbc数据源的事务管理器-->
<bean id="transactionManager"               class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource"/>
</bean>

   <!—定义拦截器-->
<bean id="transactionInterceptor"
      class="org.springframework.transaction.interceptor.TransactionInterceptor">
    <property name="transactionManager">
    <ref bean="transactionManager"/>
    </property>
        <property name="transactionAttributes">
            <props>
                <prop key="insert*">PROPAGATION_REQUIRED</prop>
                <prop key="update*">PROPAGATION_REQUIRED</prop>
                <prop key="save*">PROPAGATION_REQUIRED</prop>
                <prop key="find*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop>
            </props>
        </property>
    </bean>

<!—定义业务对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService.target"
       class="com.prs.application.ehld.sample.biz.service.impl.SampleServiceImpl">
<property name="userInfoDAO"
    ref="com.prs.application.ehld.sample.integration.dao.userInfoDAO">
</property>
</bean>

<!—定义业务对象的事务代理对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService" class="org.springframeword.aop.framework.ProxyFacgtoryBean">
<property name="target"
    ref="com.prs.application.ehld.sample.biz.service.sampleService.target">
</property>
<property name="interceptorNames">
    <value>transactionInterceptor</value>
</property>
</bean>

通过ProxyFacgtoryBean和TransactionInterceptor组合使用,可以对事务进行更多的控制。所有需要事务控制的对象可以共享一个transactionInterceptor的事务属性。

(2) 使用TransactionProxyFactoryBean

<!—定义业务对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService.target"
       class="com.prs.application.ehld.sample.biz.service.impl.SampleServiceImpl">
<property name="userInfoDAO"
    ref="com.prs.application.ehld.sample.integration.dao.userInfoDAO">
</property>
</bean>

    <!—定义业务对象的事务代理对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
          abstract="true">
        <property name="transactionManager">
            <ref bean="transactionManager"/>
        </property>
<property name="target"
          ref="com.prs.application.ehld.sample.biz.service.sampleService.target" />
        <property name="transactionAttributes">
            <props>
                <prop key="insert*">PROPAGATION_REQUIRED</prop>
                <prop key="update*">PROPAGATION_REQUIRED</prop>
                <prop key="save*">PROPAGATION_REQUIRED</prop>
                <prop key="find*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop>
            </props>
        </property>
    </bean>

使用TransactionProxyFactoryBean需要为每一个代理对象都去定义自己的事务属性。

(3) 使用TransactionProxyFactoryBean及abstract属性来简化配置
这种方工也是目前使用得最多的一种声明式事务配置方法


<!--事务控制代理抽象定义 -->
<bean id="baseTransactionProxy" class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean"
        abstract="true">
        <property name="transactionManager">
            <ref bean="transactionManager"/>
        </property>
        <property name="transactionAttributes">
            <props>
                <prop key="insert*">PROPAGATION_REQUIRED</prop>
                <prop key="update*">PROPAGATION_REQUIRED</prop>
                <prop key="save*">PROPAGATION_REQUIRED</prop>
                <prop key="find*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop>
            </props>
        </property>
    </bean>

<!—定义业务对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService.target"
       class="com.prs.application.ehld.sample.biz.service.impl.SampleServiceImpl">
<property name="userInfoDAO"
    ref="com.prs.application.ehld.sample.integration.dao.userInfoDAO">
</property>
</bean>

<!—定义业务对象的事务代理对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService" parent="baseTransactionProxy">
<property name="target"
    ref="com.prs.application.ehld.sample.biz.service.sampleService.target">
</property>
</bean>

使用abstract属性,可以让代理对象可以共享一个定义好的事务属性,使配置简化。

(4)使用BeanNameAutoProxyCreator
    <!—定义拦截器-->
<bean id="transactionInterceptor"
      class="org.springframework.transaction.interceptor.TransactionInterceptor">
    <property name="transactionManager">
    <ref bean="transactionManager"/>
    </property>
        <property name="transactionAttributes">
            <props>
                <prop key="insert*">PROPAGATION_REQUIRED</prop>
                <prop key="update*">PROPAGATION_REQUIRED</prop>
                <prop key="save*">PROPAGATION_REQUIRED</prop>
                <prop key="find*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="get*">PROPAGATION_SUPPORTS,readOnly</prop>
                <prop key="*">PROPAGATION_SUPPORTS,readOnly</prop>
            </props>
        </property>
    </bean>


<!—定义bean别名自动代理创建器-->
<bean id="autoProxyCreator"
   class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="interceptorNames">
       <value>transactionInterceptor</value>
    </property>
    <property name="beanNames">
    <list>
    <idref local="com.prs.application.ehld.sample.biz.service.sampleService"/>
    </list>
    </property>
</bean>

<!—定义业务对象-->
<bean id="com.prs.application.ehld.sample.biz.service.sampleService"
       class="com.prs.application.ehld.sample.biz.service.impl.SampleServiceImpl">
<property name="userInfoDAO"
    ref="com.prs.application.ehld.sample.integration.dao.userInfoDAO">
</property>
</bean>

使用BeanNameAutoProxyCreator可以由框架来提供适当的代理,由一个transactionInterceptor统一定义事务属性,只需要把需要事务控制的bean加到beannames的列表。
  对于需要大量声明式事务的bean,BeanNameAutoProxyCreator是十分方便的。减少了代理bean的定义,还可以灵活的决定一个bean是否进行事务控制。


上面四种方法是在Spring中常见的声明式事务配置方法,其中使用TransactionProxyFactoryBean及abstract属性进行配置是最常见的简化方法。



http://www.iteye.com/topic/72435












posted @ 2012-03-04 17:48 abin 阅读(528) | 评论 (0)编辑 收藏

一.
使用TransactionProxyFactoryBean创建事务代理(通常事务代理以Service层为目标bean)
<bean id="personService" class="com.lin.personServiceImpl">
    <property name="personDao" ref="personDao"/>
</bean>
//配置hibernate的事务管理器,使用HibernateTransactionManager类,该类实现了PlatformTransactionManager接口,针对hibernate 持久化连接的特定实现
<bean id="transactionManager" class="org.springframework.orm.hibernate3.HibernateTransactionManager">
    <property name="sessionFactory" ref="sessionFactory"/>
</bean>
//配置personService bean的事务代理
<bean id="personServiceProxy"
        class="org.springframework.transaction.interceptor.TransactionProxyFactoryBean">
            //指定事务管理器
    <property name="transactionManager" ref="transactionManager"/>
            //指定需要生成代理的日标bean
    <property name="persionService" ref="persionService"/>
            //指定事务属性
    <property name="transactionAttributes"
        <props>
            <prop key="insert*">PROPAGATION_REQUIRED,-MyCheckedException</prop>
            <prop key="update*>PROPAGATION_REQUIRED</prop>
            <prop key="*">PROPAGATION_REQUIRED,readOnly</prop>
        </props>
    </property>


二.使用自动创建代理简化事务配置
   使用BeanNameAutoProxyCreator 和DefaultAdvisorAutoProxyCreator创建代理时,并不一定是创建事务代理,关键在于传入的拦截器,如果传入事务拦截器,将可自动生成事务代理.
//使用jdbc局部事务策略
<bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
    <property name="dataSource" ref="dataSource"/>
</bean>
//配置目标bean1,该目标bean将由Bean后处理器自动生成代理
<bean id="testbean1" class="com.lin.Testbean1Impl">
    <property name="dataSource" ref="dataSource"/>
</bean
//配置目标bean2,该目标bean将由Bean后处理器自动生成代理
<bean id="testbean2" class="com.lin.Testbean2Impl">
    <property name="dataSource" ref="dataSource"/>
</bean
//配置事务拦截器bean
<bean id="transactionInterceptor"
   class="org.springframework.transaction.interceptor.TransactionInterceptor">
        //事务拦截器需要注入一个事务管理器
      <property name="transactionManager" ref="transactionManager"/>
       <property name="transactionAttributes">
            //定义事务传播属性
            <props>
                    <prop key="insert*">PROPAGATION_REQUIRED</prop>
                    <prop key="find*">PROPAGATION_REQUIRED,readOnly</prop>
                    <prop key="*">PROPAGATION_REQUIRED</prop>
            </props>
        </property>
    //定义BeanNameAutoProxyCreator的Bean后处理器
<bean class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
    <property name="beanNames">
        <list>
            <value>testbean1</value>
            <value>testbean2</value>
        </list>
            //此处可以增加其他需要创建事务代理的bean
    </property>
        //定义BeanNameAutoProxyCreator所需要的拦截器
     <property name="interceptorNames">
        <list>
            <value>transactionInterceptor</value>
                //此处可以增加其他新的Interceptor
        </list>
    </property>
</bean>
posted @ 2012-03-04 16:37 abin 阅读(349) | 评论 (0)编辑 收藏

仅列出标题
共50页: First 上一页 42 43 44 45 46 47 48 49 50 下一页