EJB入门经典.ppt

大家可能会问，为何不一开始就给资源加上排他锁？我们知道资源加上排他锁后是不允许再放置别的锁的，这样导致了连简单的查询都需要等待，无疑影响了并发性能。如果使用的是更新所，他可以和共享锁同时存在，这样查询操作就能立即执行，从而提高了并发性能。 什么条件下加锁：当一个事务执行update语句时，数据库会为事务分配一把更新锁。 解锁时间：当读取数据完毕，执行更新操作时，会把更新锁升级为排他锁。 与其他锁的兼容性：更新所与共享锁是兼容的，也就是说，一个资源可以同时放置更新锁和共享锁，但是最多只能放置一把更新锁。这样，当多个事务更新相同的数据时，只有一个数据能获得更新锁，然后再把更新所升级为排他锁，其他事务必须等到前一个事务结束后，才能获得更新锁，这就避免了死锁。 并发性能：允许多个事务同时读取锁定的资源，但不允许其他事务修改它。 快照是在事务开始时针对当时数据的一个静态视图。它没有对资源加锁，因此它不属于真正意义上的锁，可是它起到了锁的作用。有些数据库是通过为每个事务提供各自独立的快照来避免使用锁，如MySQL和Oracle等。快照可以避免脏读、不可重复读和幻读。 锁机制能有效地解决各种并发问题，但是它会影响并发性能。根据用户实际的需要，数据库系统提供了4中事务隔离级别供用户选择。我们可以把他们看做是4中资源加锁的方案，不同的隔离级别采用不同的锁类型来实现。在4中隔离级别中，Serializable的隔离级别最高，Read Uncommited的隔离级别最低。大多数数据库默认的隔离级别为Read Commited，如SQL Server，当然也有少部分数据库默认的隔离级别为Repeatable Read，如MySQL。 Read Uncommited: 读未提交数据 Read Commited: 读已提交数据 Repeatable Read: 可重复读 Serializable: 串行化 该选项指示数据库读取数据时不使用任何锁。在这种情况下，事务可以读取到为被提交的数据，会出现脏读、不可重复读和幻读现象。 该选项只能返回“读取时间点”以前已提交的数据，因此可以避免脏读。但重复读取数据时，返回的都是跟读取时间点有关的数据。例如12:01读取一次，返回的是12:01之前其他事务已提交过的数据（当然自己事务所做的修改也会被返回），12:03再读取一次，返回的是12:03之前其他事务已提交过的数据。因此，此选项会出现不可重复读，另外还会出现幻读现象。 该选项能够保证可重复读，可以避免脏读和不可重复读。通常有两种方法能够保证可重复读：第一种是在事务范围内锁定所读的数据，不允许其他事务对其进行修改，一般使用共享锁锁定数据；第二种是使用数据快照，保证重复读取数据时，只返回第一次读取数据所确定的快照，这样不但避免了脏读和不可重复读，还避免了幻读。比较着两种方案，由于第二种使用了快照代替共享锁，其他事务可以对数据进行修改，显然其并发性能更好些。 对SQL Server而言，它默认使用的是第一种方案，共享锁直到事务结束时才解锁，所以其他事务不能修改其读取的数据，除此之外，它还会出现幻读现象。SQL Server的这种隔离级别并发性能不怎么好，如果用的是SQL Server2005版本，可以考虑使用快照隔离级别。 对MySQL和Oracle而言，它们使用的是第二种方案，除了可以避免脏读和不可重复读，还可以避免幻读。 该选项能够避免脏读、不可重复读和幻读现象，是最严格的隔离界别。该选项指示数据库读取数据时，使用共享锁，该锁在事务结束时才解除，这样保证在事务执行结束前，其他事务不能对其所读取的数据进行修改。在两个并发事务内，如果这两个事务都获得了一把共享锁，而且都试图更新同一数据，由于需要等待对方解除共享锁，所以会出现死锁现象。 一般而言，隔离级别越是严格，系统性能就越是下降，因为它会禁止不同事务访问相同的数据。如果隔离级别非常严格，例如在Serializable级别，所有事务会出现经常性的排队等待执行，导致系统变得非常缓慢。因此应该避免在不必要的时候使用Serializable隔离级别。 有些时候执行一个查询会返回成千上万条记录，事实上我们只需要显示其中一部分数据。这时我们需要对结果集进行分页，QueryAPI 有两个接口方法可以解决这个问题：setMaxResults( ) 和setFirstResult( ) setMaxResults 方法设置获取多少条记录 setFirstResult 方法设置从结果集中的哪个索引开始获取（索引从0 开始） public ListPerson getPersonList(int max, int whichpage) { int index = (which1)