DB2 default transaction and concurrent Lock Mechanism

Today, I tried DB2's concurrent lock mechanism. The result is similar to that of MSSQL:

1. default behavior of DB2. Transactions start with executable SQL and end with COMMIT or ROLLBACK;

2. Whether or not DB2 is submitted by default depends on different tools. This is also a feature of DB2, which has obvious dependence on the external environment. For example, user authentication is dependent on the operating system or third-party authentication.

3. My experiment today is like this:

(1) Start DB2CLP, db2cmd-> db2

(2) connect to the TEST database and connect to test

(3) create a test table, create table test (id int, aa varchar (10 ))

(4) Verify the table structure, describe table test

(5) insert two rows of data, insert into test values (1, 'aaa ')

Insert into test values (2, 'bbbbbb ')

(6) verify the data, select * from test

H historical commands;

R n runs the nth command;

E n: edit the nth command;

(7) update test set aa = 'cccccc' where id = 1

(8) start another DB2CLP and update test set aa = 'ddddd' where id = 1. The result is not blocked. It is a big shock. It is said that ORACLE locks are unique, I didn't expect DB2 locks to be unique. I thought something was wrong. I checked it.
DB2 documentation and Result: Is DB2 automatically submitted dependent on interfaces or tools? What is the default option of DB2CLP?

(9) query various command options under DB2CLP, list command options;

(10) Result option c is ON by default, which means that SQL commands are automatically submitted by default in DB2CLP.

(11) change the C option to OFF and update command options using c off. Note that this option should be changed in every DB2CLP because this command only affects the current connection.

(12) after modifying the C option in the three DB2CLP connections, start the test;

(13) In the first DB2CLP, update test set aa = 'eeeee' where id = 1;

In the second DB2CLP, update test set aa = 'ffffff' where id = 1;

The result is blocked. In the third DB2CLP, update test set aa = 'gggggg' where id = 2;

It is also blocked, indicating that db2 not only blocks the modification of data in the same row, but also blocks different rows
The row Modification on the page seems to have the same lock model as MSSQL, which is a pessimistic model.

During this period of time, I have been reading DB2 data. I have benefited a lot and compared the lock models of various systems. The results show that DB2 and MSSQL are similar, I further tracked MSSQL locks and found that MSSQL adds table-level locks to the tables involved in uncommitted transactions. This will block other transactions from modifying the tables involved in the transaction. It also blocks the read operations of other transactions.

For ORACLE and MYSQL, this type of table or block-level blocking will not be generated. The reason is mainly because of the different lock models, or the cause of optimism and pessimism. Let's not talk about who is good or who is bad. We only see the concurrency, but do not see the disadvantages that optimistic locks will bring to applications. We simply say that pessimistic locks are not good, it is undeniable that optimistic locks of ORACLE and other systems will bring the benefits of system performance, making everyone comfortable at home, and application processing will be troublesome. This is also DB2, the reason why MSSQL never changes this is different.