ResultSet.TYPE_SCROLL_SENSITIVE到底发生了什么?
发布日期:2021-07-12 08:49:00 浏览次数:13 分类:技术文章

本文共 2660 字,大约阅读时间需要 8 分钟。

转自:

这个问题我在几年前说过,但今天再次从CSDN上看到有人问这个问题,可以看出,真正懂这个问题的人1%都不到。

我再次把这个问题写在这里,希望光临我的BLOG的人能真正了解它。

我们先来做一个例子,在例子中我用的是mysql-essential-5.1.30-win32版。

来跟我做以下几个命令:

mysql> create database axman;

mysql> use axman;
mysql> create table axmantest(
    -> id int(4) not null auto_increment primary key
    -> name varchar(20));

mysql> insert into axmantest (name) values ('axman')

mysql> insert into axmantest (name) values ('sager')
mysql> insert into axmantest (name) values ('p4');

OK,写一个测试程序:

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.ResultSet;
import java.sql.Statement;

public class MainTest {
 public static void main(String[] args) throws Exception{
  
  Class.forName("org.gjt.mm.mysql.Driver");
  Connection conn = DriverManager.getConnection("jdbc:mysql://localhost:3306/axman?useUnicode=true&characterEncoding=UTF-8","root","password");
  Statement stmt = conn.createStatement( ResultSet.TYPE_SCROLL_SENSITIVE,ResultSet.CONCUR_UPDATABLE);
  ResultSet rs = stmt.executeQuery("select * from axmantest");
  System.out.println("请删除!");
  Thread.sleep(1000*20);
  while(rs.next()){
   System.out.println(rs.getString(1)+","+rs.getString(2));
  }
  rs.close();
  stmt.close();
  conn.close();
 }
}

先在刚才的MYSQL命令环境下输入命令:

select * from axmantest;
+----+-------+
| id | name  |
+----+-------+
|  1 | axman |
|  2 | sager |
|  3 | p4    |
+----+-------+
3 rows in set (0.00 sec)

delete from axmantest where id = 3;不要提交,敲好放在这儿,运行那个测试程序。看到“请删除”三个字立即切换到

Mysql命令环境下回车。
跟着:
select * from axmantest;
+----+-------+
| id | name  |
+----+-------+
|  1 | axman |
|  2 | sager |
+----+-------+
2 rows in set (0.00 sec)

回到测试程序,看看:

1,axman
2,sager
3,p4

我的个神啦,这哪叫结果集敏感啊?完全是INSENSITIVE嘛!

但是,这正是TYPE_SCROLL_SENSITIVE造成的。

对于TYPE_SCROLL_INSENSITIVE,一次查询的结果可能存在数据库端的内存缓冲中,也可以直接发送到JVM的内存中,

如果结果集很小,会直接发送到JVM层,然后被next定位,转换数据类型,显示,或者缓存在数据库内存中。总之
查询结果已经和数据库脱离,这时如果数据库记录被其它进程更新,则结果集无法得知,还是使用缓存的记录。

而对于TYPE_SCROLL_SENSITIVE,一次查询的结果并不是直接的记录被缓存下来,只是符合条件的记录的“原始ROWID”

被缓存了,这个原始ROWID并非特指ORACLE的ROWID,而是数据库底层定位记录的索引值。简单说
select * from axmantest操作的结果并不是
1,axman
2,sager
3,p4
这些内容被缓存了。而是类似rd_file_offset_0x111010101001这样的值被缓存了,然后next定位到这条记录时,
数据库会再次根据这个ROWID做底层操作:
select * from axmantest where rowid = rd_file_offset_0x111010101001;
简单说每next一次都会发生一次查询,这样可以保证next后操作到的是当前最新的数据。
对于更新操作,如果你先查询,然后数据被其它进程更新掉了,然后next到这条记录时肯定没有问题,会取出最新的
内容,但对于删除操作。因为数据库删除记录只是记录上做一个标记,不再被检索,但原来被缓存的ROWID还在,根据
它还可以通过数据库自己的底层操作正确地把数据提取出来,所以你看到的已经被手工删除的数据又被显示出来了。

同样插入操作因为查询的时候结果集中还没有要插入的操作,所以不可能缓存了它的ROWID,我们再次做这个例子,把

“请删除”修改成“请插入”(有些不好听),现在数据库中是两条记录,当运行程序看到“请插入”时立即插入,注意
我说的是往表中插入记录,不是插入别的。然后看一下运行结果还是两条记录。

如果有兴趣再试一下更新操作,你会看更新的结果会马上反映出来。

所以TYPE_SCROLL_SENSITIVE只能更新操作敏感,其它的插入操作和删除操作不会及时地反映到结果集中。

转载于:https://www.cnblogs.com/wq3435/p/9049555.html

转载地址:https://blog.csdn.net/ankan7400/article/details/102088901 如侵犯您的版权,请留言回复原文章的地址,我们会给您删除此文章,给您带来不便请您谅解!

上一篇:AMD 规范使用总结
下一篇:Redis基础、高级特性与性能调优

发表评论

最新留言

初次前来,多多关照!
[***.217.46.12]2024年04月14日 13时18分46秒