What happened to resultset. type_scroll_sensitive?

I have said this question a few years ago, but today I am again seeing someone asking this question from csdn. We can see that 1% of the people who really understand this question cannot.
I once again wrote this question here, hoping that the people who visit my blog can really understand it.

Let's take an example. In this example, I use the mysql-essential-5.1.30-win32 version.

To run the following commands with me:

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, write a test program:
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.exe cutequery ("select * From axmantest ");
System. Out. println ("please delete! ");
Thread. Sleep (1000*20 );
While (Rs. Next ()){
System. Out. println (Rs. getstring (1) + "," + Rs. getstring (2 ));
}
Rs. Close ();
Stmt. Close ();
Conn. Close ();
}
}

Run the following command in the MySQL command environment:
Select * From axmantest;
+ ---- + ------- +
| ID | Name |
+ ---- + ------- +
| 1 | axman |
| 2 | Sager |
| 3 | P4 |
+ ---- + ------- +
3 rows in SET (0.00 Sec)

Delete from axmantest where id = 3; do not submit it. Click here to run the test program. When you see the word "delete", switch
Press enter in the MySQL command environment.
Follow these steps:
Select * From axmantest;
+ ---- + ------- +
| ID | Name |
+ ---- + ------- +
| 1 | axman |
| 2 | Sager |
+ ---- + ------- +
2 rows in SET (0.00 Sec)

Go back to the test procedure and see:
1, axman
2, Sager
3, p4

My God, how is this sensitive result set? Completely insensitive!

However, this is caused by type_scroll_sensitive.

For type_scroll_insensitive, the results of one query may be stored in the memory buffer of the database or directly sent to the JVM memory,
If the result set is small, it is directly sent to the JVM layer and positioned by next to convert the data type, display, or cache in the database memory. In short
The query result has been detached from the database. If the database record is updated by another process, the result set cannot be known and the cached record is still used.

For type_scroll_sensitive, the results of a query are not directly cached, but the "original rowid" of the matching records"
The original rowid is not the rowid of Oracle, but the index value of the underlying location record of the database. Simply put
The result of the select * From axmantest operation is not
1, axman
2, Sager
3, p4
These contents are cached. Instead, the value like rd_file_offset_0x111010101001 is cached, and when next locates this record,
The database will perform the underlying operations based on the rowid again:
Select * From axmantest where rowid = rd_file_offset_0x111010101001;
Simply put, a query occurs every time next, which ensures that the latest data is operated after next.
For the update operation, if you first query the data and the data is updated by other processes, and then there will be no problem when the next record arrives, the latest
Content, but for the delete operation. Because the database deletion record only marks the record and is not retrieved, but the previously cached rowid is still
It can also correctly extract data through the underlying operations of the database itself, so the data you see that has been manually deleted is displayed again.

Similarly, the insert operation cannot cache its rowid because there is no insert operation in the result set during the query. In this example
"Please delete" and change it to "Please insert" (some are not nice). Now there are two records in the database. When the running program sees "Please insert", insert it immediately. Note:
I am talking about inserting records into the table, not anything else. Then let's take a look at the running result as two records.

If you are interested in the update operation, you will see that the update results will be immediately reflected.

Therefore, type_scroll_sensitive can only update sensitive data. Other insert and delete operations are not reflected in the result set in a timely manner.