Transaction Processing
Index:
There are two modes for managing transactions within JDBC:
java.sql.Connection.setAutoCommit(boolean autoCommit) is used to switch between the two modes. If a connection is in auto-commit mode, then all its SQL statements will be executed and committed as individual transactions. Otherwise, its SQL statements are grouped into transactions that are terminated by a call to either the method java.sql.Connection.commit or the method java.sql.Connection.rollback. By default, new connections are in auto-commit mode. After an application turns auto-commit off, a transaction is started. The transaction continues until either the java.sql.Connection.commit meothod, COMMIT [WORK] sql, the java.sql.Connection.rollback method, or ROLLBACK [WORK] sql is called; after that a new transaction is automatically started.
Calling the commit method ends the transaction. At that stage, HXTT DBF checks whether the transaction is valid and raises an exception if a conflict is identified. If a conflict is encountered, your application should determine how to continue, for example whether to automatically retry the transaction or inform the user of the failure. A request to rollback a transaction causes HXTT DBF to discard any changes made since the start of the transaction and to end the transaction.
connection.setAutoCommit(false); // Explicit transaction handling Statement stmt = connection.createStatement(); // Loop until transaction successful (or max retry exceeded) for(int count=0;; count++) { stmt.executeUpdate(yourSQL); try{ connection.commit(); // Commit transaction break; }catch(SQLException sqe) { // Check commit error if(sqe.getSQLState().equals("40000")) { //You can use sqle.getNextException() to know more information // Check number of times the transaction has been attempted if (count<3) { continue; } } throw sqle; } }
An isolation level represents a particular locking strategy employed in the HXTT DBF to improve data consistency. The higher the isolation level, the more locking or snapshot involved, and the more time users may spend waiting for data to be freed by another user. The isolation level provided by the HXTT DBF determines whether a transaction will encounter the following behaviors in data consistency:
Isolation Level |
Dirty Read |
Non-repeatable Read |
Phantom Read |
None |
Yes |
Yes |
Yes |
Read uncommitted |
Yes |
Yes |
Yes |
Read committed |
No |
Yes |
Yes |
Repeatable read |
No |
No |
Yes |
Serializable |
No |
No |
No |
HXTT DBF supports all isolation levels.>
With Read uncommitted level, all rollbacked rows are visible in Xbase applicatons as deleted rows.