InnoDB transactions and Logs & JTA transactions

What is the InnoDB engine's Row lock done (or implemented) by adding? Why is that so?

multiple versioning via row

MyISAM Innodb

Things support: Support Not supported

Size of Lock: Table Row

Storage capacity: No upper limit 64TB

Hash index: Support not supported

Full-Text indexing : Support Not supported

FOREIGN key : Support Not supported

(1) How many kinds of logs are there?

Error log: Log error messages, also record some warning messages or correct information

Slow query log: Sets a threshold that records all SQL statements that run longer than this value to the log file for slow queries.

Binary log: Records all actions that make changes to the database

Query log: Records all information about database requests, whether or not they are executed correctly.

(2) The form of log storage

(3) how the transaction is achieved through the log , the more deeply the better.

Isolation: Implemented by lock

Atomicity, consistency, and persistence are accomplished through redo and undo.

Several log entry formats and differences for MySQL Binlog

(1) The meaning of various log formats

(2) Applicable scenarios

(3) Combining the first problem, each log format in the copy of the pros and cons.

JDBC Transactionis controlled with the Connection object. The JDBC Connection Interface (java.sql.Connection) provides two transaction modes: Autocommit and Manual commit. Java.sql.Connection provides the following methods for controlling transactions: public void Setautocommit (Boolean) public boolean getautocommit () public void commit () public void rollback () When using JDBC transaction demarcation, you can combine multiple SQL statements into a single transaction. One drawback of JDBC transactions is that the scope of a transaction is limited to a single database connection. A JDBC transaction cannot span multiple databases. JTA (Java Transaction API) transactionJTA is a high-level, unrelated, protocol-agnostic API that enables applications and application servers to access transactions using JTA. JTA allows applications to perform distributed transactions-access and update data on two or more network computer resources, which can be distributed across multiple databases. The JTA support of the JDBC driver greatly enhances the data access capability. If you plan to define transactions with JTA, you need a JDBC driver that implements the Javax.sql.XADataSource, Javax.sql.XAConnection, and Javax.sql.XAResource interfaces. A driver that implements these interfaces will be able to participate in the JTA transaction. A Xadatasource object is a factory of a Xaconnection object. Xaconnection S is a JDBC connection that participates in JTA transactions. You will need to set up Xadatasource with the Application Server's administration tool. The relevant guidance can be learned from the application server and the documentation for the JDBC driver. The Java EE application queries the data source with JNDI. Once the application finds the data source object, it calls Javax.sql.DataSource.getConnection () to get a connection to the database. XA connections are not the same as non-XA connections. Be sure to remember that the XA connection participates in the JTA transaction. This means that the XA connection does not support the auto-commit feature of JDBC. Also, the application must not call Java.sql.Connection.commit () or Java.sql.Connection.rollback () on the XA connection. Instead, applications should use Usertransaction.begin (), Usertransaction.commit (), and Sertransaction.rollback ().

InnoDB transactions and Logs & JTA transactions