The first step in the process of creating a connection between Java applications and databases is to register a JDBC driver with "Java Virtual Machine (Java Virtual Machine (JVM). Java application is running in this JVM. In the traditional connection mechanism (relative to the DataSource connection mechanism discussed later), the connection and all database communications are controlled by the DriverManager object. To create a connection, you must register the appropriate JDBC driver for the target database with the DriverManager object. The transaction foundation is very easy to understand in single user mode, and they are only related to the status of saving or forgetting applications. However, in multi-user mode, transactions become more complicated. The classic explanation of multi-user transactions is a bank account, one of which tries to decept your account, and another application tries to make an account with an account. If you are familiar with concurrent programming (also called multi-threaded programming), you have seen this problem before. The fundamental problem is that an application may affect the other, unless the two transactions are isolated from each other, resulting in an incorrect program state. In our simple description, this may mean that there is an income amount in an account, which will not benefit from customer.
When handling multiple users accessing the same data, three problems may often occur:
Dirty. When the application uses data modified by another application, dirty reading occurs when this data is in a failed state. The second application will then request back the data that is modified by it. The data used by the first transaction will be damaged, or "changing the dirty". Not repeatable reading. When a transaction obtains data, the data is then changed by a separate transaction, if the first transaction reads the changed data again, it will occurs. In this way, the first transaction has been unusable read. Misfiring. When the transaction gets data through some kind of query, another transaction has changed some of the data. When the original transaction gets this data, it will happen. The first transaction will now have different result sets, which may contain false reading. In order to solve problems associated with the "multiple thread requests the same data", the transaction is separated from each other. Most mainstream databases support different types of locks; therefore, JDBC API supports different types of transactions, which are assigned or determined by the Connection object. The following transaction level can be obtained in the JDBC API:
Transaction_none shows that transactions are not supported. Transaction_read_uncommitted Description Change of another transaction can be seen in the previous transaction. This is allowed to read and unusual readings are allowed. Transaction_read_committed Description Read Unspendumed data is not allowed. This level still allows for non-repetitive read and miscompasses. Transaction_repeATable_read Description Transaction ensures that the same data can be read again without fail, but misfiring will still appear. Transaction_Serializable is the highest transaction level, which prevents dirty reading, non-repetitive readings and false readings. You may want to know why not all transactions run in Transaction_Serializable mode to ensure the highest level of data integrity? The problem is that the problems related to processing multi-threaded programming are similar, the higher the level of transaction protection, the greater performance loss. Assume that your database and JDBC driver support this feature, give a Connection object, you can set the desired transaction level: con.settransactionLevel (Transaction_Serializable);
You can also determine the level of the current transaction:
IF (con.gettransactionlevel () == Transaction_serializable) System.out.println ("Highest Transaction Level In Operation);
Batch and transaction Many database support batch operations, which can be minimized by performing multiple database updates in a single operation (or batch) in a batch operation. Batch operation is introduced in JDBC 2.0, which requires the transaction to be automatically submitted. The batch operation is illustrated in the example below, where there is a connection in the database that contains a simple table.
Con.SetAutocommit (False);
Statement Stmt = Connection.createStatement ();
Stmt.addbatch ("INSERT INTO People Values ('Joe Jackson', 0.325, 25, 105);
Stmt.addbatch ("INSERT INTO People VALUES ('Jim Jackson', 0.349, 18, 99);
Stmt.addbatch ("INSERT INTO People VALUES ('Jack Jackson', 0.295, 15, 84);
int [] Updatecounts = stmt.executebatch ();
C.Commit ();
Note that the executebatch () method returns an array of update counts, each value corresponding to a command of the batch operation. The last problem with the batch operation is that they may throw a new exception that is BatchUpdateException, which indicates that at least one of the commands in the batch operation failed. This way you need to add an appropriate exception handler in a batch operation.
