Spring学习笔记4-JDBC
1、
为了使 JDBC 更加易于使用, Spring 在 JDBC API 上定义了一个抽象层, 以此建立一个 JDBC 存取框架.
作为 Spring JDBC 框架的核心, JDBC 模板的设计目的是为不同类型的 JDBC 操作提供模板方法. 每个模板方法都能控制整个过程, 并允许覆盖过程中的特定任务. 通过这种方式, 可以在尽可能保留灵活性的情况下, 将数据库存取的工作量降到最低.
2、简化 JDBC 模板查询
每次使用都创建一个 JdbcTemplate 的新实例, 这种做法效率很低下.
JdbcTemplate 类被设计成为线程安全的, 所以可以再 IOC 容器中声明它的单个实例, 并将这个实例注入到所有的 DAO 实例中.
JdbcTemplate 也利用了 Java 1.5 的特定(自动装箱, 泛型, 可变长度等)来简化开发
Spring JDBC 框架还提供了一个 JdbcDaoSupport 类来简化 DAO 实现. 该类声明了 jdbcTemplate 属性, 它可以从 IOC 容器中注入, 或者自动从数据源中创建.
3、在 JDBC 模板中使用具名参数
在经典的 JDBC 用法中, SQL 参数是用占位符 ? 表示,并且受到位置的限制. 定位参数的问题在于, 一旦参数的顺序发生变化, 就必须改变参数绑定.
在 Spring JDBC 框架中, 绑定 SQL 参数的另一种选择是使用具名参数(named parameter).
具名参数: SQL 按名称(以冒号开头)而不是按位置进行指定. 具名参数更易于维护, 也提升了可读性. 具名参数由框架类在运行时用占位符取代
具名参数只在 NamedParameterJdbcTemplate 中得到支持
在 SQL 语句中使用具名参数时, 可以在一个 Map 中提供参数值, 参数名为键
也可以使用 SqlParameterSource 参数
批量更新时可以提供 Map 或 SqlParameterSource 的数组
4、事务管理
事务的四个关键属性(ACID)
--原子性(atomicity): 事务是一个原子操作, 由一系列动作组成. 事务的原子性确保动作要么全部完成要么完全不起作用.
--一致性(consistency): 一旦所有事务动作完成, 事务就被提交. 数据和资源就处于一种满足业务规则的一致性状态中.
--隔离性(isolation): 可能有许多事务会同时处理相同的数据, 因此每个事物都应该与其他事务隔离开来, 防止数据损坏.
--持久性(durability): 一旦事务完成, 无论发生什么系统错误, 它的结果都不应该受到影响. 通常情况下, 事务的结果被写到持久化存储器中.
作为企业级应用程序框架, Spring 在不同的事务管理 API 之上定义了一个抽象层. 而应用程序开发人员不必了解底层的事务管理 API, 就可以使用 Spring 的事务管理机制.
Spring 既支持编程式事务管理, 也支持声明式的事务管理.
编程式事务管理: 将事务管理代码嵌入到业务方法中来控制事务的提交和回滚. 在编程式管理事务时, 必须在每个事务操作中包含额外的事务管理代码.
声明式事务管理: 大多数情况下比编程式事务管理更好用. 它将事务管理代码从业务方法中分离出来, 以声明的方式来实现事务管理. 事务管理作为一种横切关注点, 可以通过 AOP 方法模块化. Spring 通过 Spring AOP 框架支持声明式事务管理.
Spring 从不同的事务管理 API 中抽象了一整套的事务机制. 开发人员不必了解底层的事务 API, 就可以利用这些事务机制. 有了这些事务机制, 事务管理代码就能独立于特定的事务技术了.
Spring 的核心事务管理抽象是接口PlatformTransactionManager管理封装了一组独立于技术的方法. 无论使用 Spring 的哪种事务管理策略(编程式或声明式), 事务管理器都是必须的.
5、Spring 中的事务管理器的不同实现
Class DataSourceTransactionManager在应用程序中只需处理一个数据源且通过JDBC存取
Class JtaTransactionManager在JavaEE应用服务器上用JTA进行事务管理（主要是分布式）
Class HibernateTransactionManager用Hibernate框架存取数据库
等等其他实现
事务管理器以普通的 Bean 形式声明在 Spring IOC 容器中
6、用事务通知声明式地管理事务
事务管理是一种横切关注点
为了在 Spring 2.x 中启用声明式事务管理, 可以通过 tx Schema 中定义的 元素声明事务通知, 为此必须事先将这个 Schema 定义添加到 根元素中去.
声明了事务通知后, 就需要将它与切入点关联起来. 由于事务通知是在 元素外部声明的, 所以它无法直接与切入点产生关联. 所以必须在 元素中声明一个增强器通知与切入点关联起来.
由于 Spring AOP 是基于代理的方法, 所以只能增强公共方法. 因此, 只有公有方法才能通过 Spring AOP 进行事务管理.
例如：
除了在带有切入点, 通知和增强器的 Bean 配置文件中声明事务外, Spring 还允许简单地用 @Transactional 注解来标注事务方法.
为了将方法定义为支持事务处理的, 可以为方法添加 @Transactional 注解. 根据 Spring AOP 基于代理机制, 只能标注公有方法.
可以在方法或者类级别上添加 @Transactional 注解. 当把这个注解应用到类上时, 这个类中的所有公共方法都会被定义成支持事务处理的.
在 Bean 配置文件中只需要启用 元素, 并为之指定事务管理器就可以了.
如果事务处理器的名称是 transactionManager, 就可以在 元素中省略 transaction-manager 属性. 这个元素会自动检测该名称的事务处理器.
7、事务传播属性
当事务方法被另一个事务方法调用时, 必须指定事务应该如何传播. 例如: 方法可能继续在现有事务中运行, 也可能开启一个新事务, 并在自己的事务中运行.
事务的传播行为可以由传播属性指定. Spring 定义了 7 种类传播行为：
--required：如果有事务在运行，当前的方法就在这个事务内运行，否则，就启动一个新事务并在自己的事物内运行@Transactional(propagation)
--required_new：当前的方法必须启动新事物并在它自己的事物内运行，如果有事务正在运行，应该将它挂起@Transactional(propagation=Propagation.REQUIRES_NEW)
--supports：如果有事务在运行，当前的方法就在这个事务内运行，否则它可以不运行在事务中
--not_supported：当前的方法不应该运行在事务中，如果有运行的事物，将它挂起
--mandatory：当前的方法必须运行在事务内部，如果没有正在运行的事物，就抛出异常
--never：当前的方法不应该运行在事务中，如果有运行的事物就抛出异常
--nested：如果有事务在运行，当前的方法就应该在这个事务的嵌套事务内运行，否则，就启动一个新的事物，并在它自己的事物内运行
8、并发事务所导致的问题
当同一个应用程序或者不同应用程序中的多个事务在同一个数据集上并发执行时, 可能会出现许多意外的问题
并发事务所导致的问题可以分为下面三种类型:
---脏读: 对于两个事物 T1, T2, T1 读取了已经被 T2 更新但 还没有被提交的字段. 之后, 若 T2 回滚, T1读取的内容就是临时且无效的.
---不可重复读:对于两个事物 T1, T2, T1 读取了一个字段, 然后 T2 更新了该字段. 之后, T1再次读取同一个字段, 值就不同了.
---幻读:对于两个事物 T1, T2, T1 从一个表中读取了一个字段, 然后 T2 在该表中插入了一些新的行. 之后, 如果 T1 再次读取同一个表, 就会多出几行.
9、事务的隔离级别
事务的隔离级别可以通过隔离事务属性指定
10、Spring 支持的事务隔离级别
--default：使用底层数据库的默认隔离级别，对于大多数数据库而言，默认隔离级别都是READ_COMMITED
--read_uncommitted：允许事务读取未被其他事务提交的变更，导致脏读、不可重复读、幻读的问题都会出现
--read_commited：只允许事务读取已经被其他事务提交的变更，允许脏读，但不可重复读和幻读问题仍然可能出现
--repeatable_read：确保事务可以多次从一个字段中读取相同的值，在这个事务持续期间，禁止其他事务对这个字段进行更新操作，虽然避免了脏读、不可重复读，但幻读的问题仍然存在
--serializable：确保事务可以从一个表中读取相同的行，但这个事务持续期间，禁止其他事务对该表执行insert、update、delete操作，所有并发问题都可以避免，但性能十分低下
事务的隔离级别要得到底层数据库引擎的支持, 而不是应用程序或者框架的支持.
Oracle 支持的 2 种事务隔离级别：READ_COMMITED , SERIALIZABLE
Mysql 支持 4 中事务隔离级别.
11、设置隔离事务属性
用 @Transactional 注解声明式地管理事务时可以在 @Transactional 的 isolation 属性中设置隔离级别.例如：isolation=Isolation.READ_COMMITED
在 Spring 2.x 事务通知中, 可以在 元素中指定隔离级别
12、设置回滚事务属性
默认情况下只有未检查异常(RuntimeException和Error类型的异常)会导致事务回滚. 而受检查异常不会.
事务的回滚规则可以通过 @Transactional 注解的 rollbackFor 和 noRollbackFor 属性来定义. 这两个属性被声明为 Class[] 类型的, 因此可以为这两个属性指定多个异常类.
---rollbackFor: 遇到时必须进行回滚
---noRollbackFor: 一组异常类，遇到时必须不回滚
在 Spring 2.x 事务通知中, 可以在 元素中指定回滚规则. 如果有不止一种异常, 用逗号分隔.
13、超时和只读属性
由于事务可以在行和表上获得锁, 因此长事务会占用资源, 并对整体性能产生影响.
如果一个事物只读取数据但不做修改, 数据库引擎可以对这个事务进行优化.
超时事务属性: 事务在强制回滚之前可以保持多久. 这样可以防止长期运行的事务占用资源.
只读事务属性: 表示这个事务只读取数据但不更新数据, 这样可以帮助数据库引擎优化事务.
14、设置超时和只读事务属性
超时和只读属性可以在 @Transactional 注解中定义.超时属性以秒为单位来计算.readOnly=true,timeout=xxx
在 Spring 2.x 事务通知中, 超时和只读属性可以在 元素中进行指定.
为了使 JDBC 更加易于使用, Spring 在 JDBC API 上定义了一个抽象层, 以此建立一个 JDBC 存取框架.
作为 Spring JDBC 框架的核心, JDBC 模板的设计目的是为不同类型的 JDBC 操作提供模板方法. 每个模板方法都能控制整个过程, 并允许覆盖过程中的特定任务. 通过这种方式, 可以在尽可能保留灵活性的情况下, 将数据库存取的工作量降到最低.
2、简化 JDBC 模板查询
每次使用都创建一个 JdbcTemplate 的新实例, 这种做法效率很低下.
JdbcTemplate 类被设计成为线程安全的, 所以可以再 IOC 容器中声明它的单个实例, 并将这个实例注入到所有的 DAO 实例中.
JdbcTemplate 也利用了 Java 1.5 的特定(自动装箱, 泛型, 可变长度等)来简化开发
Spring JDBC 框架还提供了一个 JdbcDaoSupport 类来简化 DAO 实现. 该类声明了 jdbcTemplate 属性, 它可以从 IOC 容器中注入, 或者自动从数据源中创建.
3、在 JDBC 模板中使用具名参数
在经典的 JDBC 用法中, SQL 参数是用占位符 ? 表示,并且受到位置的限制. 定位参数的问题在于, 一旦参数的顺序发生变化, 就必须改变参数绑定.
在 Spring JDBC 框架中, 绑定 SQL 参数的另一种选择是使用具名参数(named parameter).
具名参数: SQL 按名称(以冒号开头)而不是按位置进行指定. 具名参数更易于维护, 也提升了可读性. 具名参数由框架类在运行时用占位符取代
具名参数只在 NamedParameterJdbcTemplate 中得到支持
在 SQL 语句中使用具名参数时, 可以在一个 Map 中提供参数值, 参数名为键
也可以使用 SqlParameterSource 参数
批量更新时可以提供 Map 或 SqlParameterSource 的数组
4、事务管理
事务的四个关键属性(ACID)
--原子性(atomicity): 事务是一个原子操作, 由一系列动作组成. 事务的原子性确保动作要么全部完成要么完全不起作用.
--一致性(consistency): 一旦所有事务动作完成, 事务就被提交. 数据和资源就处于一种满足业务规则的一致性状态中.
--隔离性(isolation): 可能有许多事务会同时处理相同的数据, 因此每个事物都应该与其他事务隔离开来, 防止数据损坏.
--持久性(durability): 一旦事务完成, 无论发生什么系统错误, 它的结果都不应该受到影响. 通常情况下, 事务的结果被写到持久化存储器中.
作为企业级应用程序框架, Spring 在不同的事务管理 API 之上定义了一个抽象层. 而应用程序开发人员不必了解底层的事务管理 API, 就可以使用 Spring 的事务管理机制.
Spring 既支持编程式事务管理, 也支持声明式的事务管理.
编程式事务管理: 将事务管理代码嵌入到业务方法中来控制事务的提交和回滚. 在编程式管理事务时, 必须在每个事务操作中包含额外的事务管理代码.
声明式事务管理: 大多数情况下比编程式事务管理更好用. 它将事务管理代码从业务方法中分离出来, 以声明的方式来实现事务管理. 事务管理作为一种横切关注点, 可以通过 AOP 方法模块化. Spring 通过 Spring AOP 框架支持声明式事务管理.
Spring 从不同的事务管理 API 中抽象了一整套的事务机制. 开发人员不必了解底层的事务 API, 就可以利用这些事务机制. 有了这些事务机制, 事务管理代码就能独立于特定的事务技术了.
Spring 的核心事务管理抽象是接口PlatformTransactionManager管理封装了一组独立于技术的方法. 无论使用 Spring 的哪种事务管理策略(编程式或声明式), 事务管理器都是必须的.
5、Spring 中的事务管理器的不同实现
Class DataSourceTransactionManager在应用程序中只需处理一个数据源且通过JDBC存取
Class JtaTransactionManager在JavaEE应用服务器上用JTA进行事务管理（主要是分布式）
Class HibernateTransactionManager用Hibernate框架存取数据库
等等其他实现
事务管理器以普通的 Bean 形式声明在 Spring IOC 容器中
6、用事务通知声明式地管理事务
事务管理是一种横切关注点
为了在 Spring 2.x 中启用声明式事务管理, 可以通过 tx Schema 中定义的
声明了事务通知后, 就需要将它与切入点关联起来. 由于事务通知是在
由于 Spring AOP 是基于代理的方法, 所以只能增强公共方法. 因此, 只有公有方法才能通过 Spring AOP 进行事务管理.
例如：
除了在带有切入点, 通知和增强器的 Bean 配置文件中声明事务外, Spring 还允许简单地用 @Transactional 注解来标注事务方法.
为了将方法定义为支持事务处理的, 可以为方法添加 @Transactional 注解. 根据 Spring AOP 基于代理机制, 只能标注公有方法.
可以在方法或者类级别上添加 @Transactional 注解. 当把这个注解应用到类上时, 这个类中的所有公共方法都会被定义成支持事务处理的.
在 Bean 配置文件中只需要启用
如果事务处理器的名称是 transactionManager, 就可以在
7、事务传播属性
当事务方法被另一个事务方法调用时, 必须指定事务应该如何传播. 例如: 方法可能继续在现有事务中运行, 也可能开启一个新事务, 并在自己的事务中运行.
事务的传播行为可以由传播属性指定. Spring 定义了 7 种类传播行为：
--required：如果有事务在运行，当前的方法就在这个事务内运行，否则，就启动一个新事务并在自己的事物内运行@Transactional(propagation)
--required_new：当前的方法必须启动新事物并在它自己的事物内运行，如果有事务正在运行，应该将它挂起@Transactional(propagation=Propagation.REQUIRES_NEW)
--supports：如果有事务在运行，当前的方法就在这个事务内运行，否则它可以不运行在事务中
--not_supported：当前的方法不应该运行在事务中，如果有运行的事物，将它挂起
--mandatory：当前的方法必须运行在事务内部，如果没有正在运行的事物，就抛出异常
--never：当前的方法不应该运行在事务中，如果有运行的事物就抛出异常
--nested：如果有事务在运行，当前的方法就应该在这个事务的嵌套事务内运行，否则，就启动一个新的事物，并在它自己的事物内运行
8、并发事务所导致的问题
当同一个应用程序或者不同应用程序中的多个事务在同一个数据集上并发执行时, 可能会出现许多意外的问题
并发事务所导致的问题可以分为下面三种类型:
---脏读: 对于两个事物 T1, T2, T1 读取了已经被 T2 更新但 还没有被提交的字段. 之后, 若 T2 回滚, T1读取的内容就是临时且无效的.
---不可重复读:对于两个事物 T1, T2, T1 读取了一个字段, 然后 T2 更新了该字段. 之后, T1再次读取同一个字段, 值就不同了.
---幻读:对于两个事物 T1, T2, T1 从一个表中读取了一个字段, 然后 T2 在该表中插入了一些新的行. 之后, 如果 T1 再次读取同一个表, 就会多出几行.
9、事务的隔离级别
事务的隔离级别可以通过隔离事务属性指定
10、Spring 支持的事务隔离级别
--default：使用底层数据库的默认隔离级别，对于大多数数据库而言，默认隔离级别都是READ_COMMITED
--read_uncommitted：允许事务读取未被其他事务提交的变更，导致脏读、不可重复读、幻读的问题都会出现
--read_commited：只允许事务读取已经被其他事务提交的变更，允许脏读，但不可重复读和幻读问题仍然可能出现
--repeatable_read：确保事务可以多次从一个字段中读取相同的值，在这个事务持续期间，禁止其他事务对这个字段进行更新操作，虽然避免了脏读、不可重复读，但幻读的问题仍然存在
--serializable：确保事务可以从一个表中读取相同的行，但这个事务持续期间，禁止其他事务对该表执行insert、update、delete操作，所有并发问题都可以避免，但性能十分低下
事务的隔离级别要得到底层数据库引擎的支持, 而不是应用程序或者框架的支持.
Oracle 支持的 2 种事务隔离级别：READ_COMMITED , SERIALIZABLE
Mysql 支持 4 中事务隔离级别.
11、设置隔离事务属性
用 @Transactional 注解声明式地管理事务时可以在 @Transactional 的 isolation 属性中设置隔离级别.例如：isolation=Isolation.READ_COMMITED
在 Spring 2.x 事务通知中, 可以在
12、设置回滚事务属性
默认情况下只有未检查异常(RuntimeException和Error类型的异常)会导致事务回滚. 而受检查异常不会.
事务的回滚规则可以通过 @Transactional 注解的 rollbackFor 和 noRollbackFor 属性来定义. 这两个属性被声明为 Class[] 类型的, 因此可以为这两个属性指定多个异常类.
---rollbackFor: 遇到时必须进行回滚
---noRollbackFor: 一组异常类，遇到时必须不回滚
在 Spring 2.x 事务通知中, 可以在
13、超时和只读属性
由于事务可以在行和表上获得锁, 因此长事务会占用资源, 并对整体性能产生影响.
如果一个事物只读取数据但不做修改, 数据库引擎可以对这个事务进行优化.
超时事务属性: 事务在强制回滚之前可以保持多久. 这样可以防止长期运行的事务占用资源.
只读事务属性: 表示这个事务只读取数据但不更新数据, 这样可以帮助数据库引擎优化事务.
14、设置超时和只读事务属性
超时和只读属性可以在 @Transactional 注解中定义.超时属性以秒为单位来计算.readOnly=true,timeout=xxx
在 Spring 2.x 事务通知中, 超时和只读属性可以在